
On 14/09/10 19:29, Bryan O'Sullivan wrote:
On Tue, Sep 14, 2010 at 11:21 AM, Edward Z. Yang
mailto:ezyang@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