Asynchronous exception wormholes kill modularity
marlowsd at gmail.com
Mon Mar 29 06:37:15 EDT 2010
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
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.
More information about the Libraries