[Haskell-cafe] Re: Guidance on using asynchronous exceptions
simonmarhaskell at gmail.com
Fri Nov 16 05:50:18 EST 2007
> 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:
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
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.
More information about the Haskell-Cafe