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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
