Asynchronous exception wormholes kill modularity
marlowsd at gmail.com
Wed Apr 7 17:50:51 EDT 2010
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:
> 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.
In the case of withMVar, if the caller is concerned about the
interruptibility then they can call it within nonInterruptibleMask,
which overrides the interruptible mask in withMVar.
More information about the Libraries