Asynchronous exception wormholes kill modularity

[Isaac Dupree]

On 04/07/10 17:50, Simon Marlow wrote:
> On 07/04/10 21:23, Bas van Dijk wrote:
>> On Wed, Apr 7, 2010 at 5:12 PM, Simon Marlow<marlowsd at gmail.com> wrote:
>>> Comments?
>>
>> I really like this design.
>>
>> One question, are you planning to write the MVar utility functions
>> using 'mask' or using 'nonInterruptibleMask'? As in:
>>
>>> withMVar :: MVar a -> (a -> IO b) -> IO b
>>> withMVar m f = whichMask? $ \restore -> do
>>> a<- takeMVar m
>>> b<- restore (f a) `onException` putMVar m a
>>> putMVar m a
>>> return b
>
> Definitely the ordinary interruptible mask. It is the intention that the
> new nonInterruptibleMask is only used in exceptional circumstances where
> dealing with asynchronous exceptions emerging from blocking operations
> would be impossible to deal with. The more unwieldy name was chosen
> deliberately for this reason.
>
> The danger with nonInterruptibleMask is that it is all too easy to write
> a program that will be unresponsive to Ctrl-C, for example. It should be
> used with great care - for example when there is reason to believe that
> any blocking operations that would otherwise be interruptible will only
> block for short bounded periods.

it could be called unsafeNonInterruptibleMask 
(unsafeUninterruptibleMask?)... after all, 'mask' is uninterruptible for 
most/many operations, that's its point, but if we put 'mask' and 
'nonInterruptibleMask' next to each other, I think people are likely to 
be confused (..less so if there's good Haddock documentation. But i'm 
fearing the 'forkOS' debacle where people still wrongly recommend that 
because the name sounds good...)

I still would like to see examples of where it's needed, because I 
slightly suspect that wrapping possibly-blocking operations in an 
exception handler that does something appropriate, along with ordinary 
'mask', might be sufficient... But I expect to be proved wrong; I just 
haven't figured out how to prove myself wrong.

-Isaac