[Haskell-cafe] Re: Guidance on using asynchronous exceptions

[Simon Marlow]

Yang wrote:
> To follow up on my previous post ("Asynchronous Exceptions and the
> RealWorld"), I've decided to put together something more concrete in
> the hopes of eliciting response.
> 
> I'm trying to write a library of higher-level concurrency
> abstractions, in particular for asynchronous systems programming. The 
> principal goal here is composability and safety. Ideally, one can apply 
> combinators on any existing (IO a), not just procedures written for this 
> library. But that seems like a pipe dream at this point.

It's quite hard to write composable combinators using threads and 
asynchronous exceptions, and this is certainly a weakness of the design. 
See for example the timeout combinator we added recently:

http://darcs.haskell.org/packages/base/System/Timeout.hs

There we did just about manage to make timeout composable, but it was tricky.

> In the code below, the running theme is process orchestration. (I've put 
> TODOs at places where I'm blocked - no pun intended.)
> 
> I'm currently worried that what I'm trying to do is simply impossible in
> Concurrent Haskell. I'm bewildered by the design decisions in the
> asynchronous exceptions paper. I'm also wondering if there are any
> efforts under way to reform this situation. I found some relevant
> posts below hinting at this, but I'm not sure what the status is
> today.

We haven't made any changes to block/unblock, although that's something I'd 
like to investigate at some point.  If you have any suggestions, I'd be 
interested to hear them.

The problem your code seems to be having is that waitForProcess is 
implemented as a C call, and C calls cannot be interrupted by asynchronous 
exceptions - there's just no way to implement that in general.  One 
workaround would be to fork a thread to call waitForProcess, and 
communicate with the thread using an MVar (takeMVar *is* interruptible). 
You could encapsulate this idiom as a combinator "interruptible", perhaps. 
  But note that interrupting the thread waiting on the MVar won't then 
terminate the foreign call: the call will run to completion as normal.

The fact that some operations which block indefinitely cannot be 
interrupted is a problem.  We should document which those are, but the fact 
that the audit has to be done by hand means it's both tedious and 
error-prone, which is why it hasn't been done.

The only example that I know of where asynchronous exceptions and 
block/unblock are really used in anger is darcs, which tries to do 
something reasonable in response to a keyboard interrupt.

Cheers,
	Simon