Asynchronous exception wormholes kill modularity

[Simon Marlow]

On 26/03/2010 19:51, Isaac Dupree wrote:
> On 03/25/10 12:36, Simon Marlow wrote:
>> I'd also be amenable to having block/unblock count nesting levels
>> instead, I don't think it would be too hard to implement and it wouldn't
>> require any changes at the library level.
>
> Wasn't there a reason that it didn't nest?
>
> I think it was that operations that block-as-in-takeMVar, for an
> unbounded length of time, are always supposed to C.Exception.unblock and
> in fact be unblocked within that operation. Otherwise the thread might
> never receive its asynchronous exceptions.

That's why we have the notion of "interruptible operations": any 
operation that blocks for an unbounded amount of time is treated as 
interruptible and can receive asynchronous exceptions.

I think of "block" as a way to turn asynchronous exceptions into 
synchronous ones.  So rather that having to worry that an asynchronous 
exception may strike at any point, you only have to worry about them 
being throw by blocking operations.  If in doubt you should think of 
every library function as potentially interruptible, but that still 
means you usually have enough control over asynchronous exceptions to 
avoid problems.

If things get really hairy, consider using STM instead.  In STM an 
asynchronous exception causes a rollback, so maintaining your invariants 
is trivial - this is arguably one of the main benefits of STM.  There's 
no need for block/unblock within STM transactions.

Cheers,
	Simon