[Haskell-cafe] Re: Cleaning up threads
marlowsd at gmail.com
Tue Sep 21 17:10:45 EDT 2010
On 14/09/10 19:29, Bryan O'Sullivan wrote:
> On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang <ezyang at mit.edu
> <mailto:ezyang at mit.edu>> 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.
More information about the Haskell-Cafe