[Haskell-cafe] Re: Asynchronous exception wormholes kill
marlowsd at gmail.com
Fri Apr 9 07:41:33 EDT 2010
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":
> That doesn't answer your question precisely however.
The semantics in our original paper 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.
More information about the Haskell-Cafe