September 12th, 2005

  • evan

asynchronous exceptions

LTU linked to Asynchronous Exceptions in Haskell. It has an amusing resolution.

They posit: Sometimes it's nice to be able to kill another thread, either because of timeouts, or user interrupts, etc. But you can't safely do it because that thread could potentially be holding locks or leaving resources in an unsafe state. What to do?

Most languages avoid killing and just require a worker thread to poll a shared flag to see whether it's time to stop. (LogJam on Windows did this at one point for cancelling threaded network requests -- you don't really cancel them, you just tell them to stop when they get the chance and hide the "processing" dialog.) This is lame, but it's just what you do.

The main conclusion is that crazy Haskell again gets nice properties for free:
While the semi-asychronous approach avoids breaking synchronization abstractions, it is non-modular in that the target code must be written to use the signalling mechanism. Worse still (for us), the semi-asynchronous approach is simply incompatible with a purely-functional language, such as Concurrent Haskell. The problem is that polling a global flag is not a functional operation, yet in a Concurrent Haskell program, most of the time is spent in purely-functional code. On the other hand, since there is absolutely no problem with abandoning a purely-functional computation at any point, asynchronous exceptions are safe in a functional setting.