[Haskell-cafe] Re: Cleaning up threads

Simon Marlow 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.

Cheers,
	Simon


More information about the Haskell-Cafe mailing list