On 14/09/10 19:29, Bryan O'Sullivan wrote:
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang <[email protected]
<mailto:[email protected]>> wrote:
Pure code can always be safely asynchronously interrupted (even code
using state like the ST monad), and IO code can be made to interact
correctly with thread termination simply by using appropriate bracketing
functions that would handle normal IO exceptions.
Ertugrul's advice is still correct. I'd wager there are very few
concurrent applications that could survive a killThread without
disaster. People simply don't write or test code with that in mind, and
even when they do, it's more likely than not to be wrong.
Avoiding killThread on its own doesn't help: Control-C sends an
asynchronous exception to the main thread, and a stack overflow also
results in an asynchronous exception. So for now to completely avoid
asynchronous exceptions you'd need to catch Control-C, and disable the
stack limit (+RTS -K1000G). I expect we'll map other fatal signals to
exceptions in the future (pending redesign of the signal API means we
haven't got to that yet).
So rather than admitting defeat here I'd like to see it become the norm
to write async-exception-safe code. It's not that hard, especially with
the new mask API coming in GHC 7.0.
Asynchronous exceptions are a major selling point of Haskell, we should
make more noise about them! Being able to sanely handle Control-C, and
the fact that a large fraction of code is async-exception-safe by
construction (because it isn't in the IO monad), are big wins.
Cheers,
Simon
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
