[Haskell-cafe] Re: Asynchronous exception wormholes kill modularity

[Simon Marlow]

On 09/04/2010 10:33, Bas van Dijk wrote:
> On Fri, Apr 9, 2010 at 3:22 AM, Isaac Dupree
> <ml at isaac.cedarswampstudios.org>  wrote:
>> OK, thanks for the link!  In fact, [tell me if my reasoning is wrong...], in
>> that fork-definition, the 'putMVar' will never block, because there is only
>> putMVar one for each created MVar.
>
> Yes that's correct.
>
>> I seem to remember that any execution of
>> putMVar that does not *actually* block is guaranteed not be interrupted by
>> asynchronous exceptions (if within a Control.Exception.block) -- which would
>> be sufficient.  Is my memory right or wrong?
>
> The following documentation seems to suggest that "any function which
> _may_ itself block is defined as interruptible":
>
> http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Exception.html#13
>
> That doesn't answer your question precisely however.

The semantics in our original paper[1] does indeed behave as Isaac 
described: only if an operation really blocks is it interruptible.

However, we've already changed this for throwTo, and potentially we 
might want to change it for other opertions too.  It's tricky to keep 
that behaviour in a multithreaded runtime, because it introduces extra 
complexity to distinguish between waiting for a response to a message 
from another CPU and actually blocking waiting for the other CPU to do 
something.  A concrete example of this is throwTo, which technically 
should only block if the target thread is inside 'mask', but in practice 
blocks if the target thread is running on another CPU and the current 
CPU has just sent a message to the other CPU to request a throwTo. 
(this is only in GHC 6.14 where we've changed the throwTo protocol to be 
message-based rather than the previous complicated arrangement of locks).

Still, I think I'd advocate using STM and/or atomicModifyIORef in cases 
like this, where it is much easier to write code that is guaranteed not 
to block and hence not be interruptible.

Cheers,
	Simon

[1] http://www.haskell.org/~simonmar/papers/async.pdf