I'm not sure whether asynchronous exceptions should be in Haskell'. I don't feel entirely comfortable about the "interruptible operations" facet of the design, and I'm hoping that STM can clean things up: after all, STM already gives you a much nicer way to program in an exception-safe way, as long as you aren't doing any real I/O. The fact that throwTo can interrupt a takeMVar, but can't interrupt a foreign call, even a concurrent one, is a bit strange. We have this odd situation in GHC right now where throwTo can interrupt threadDelay on Unix, but not on Windows because threadDelay maps directly to a foreign call to Sleep() on Windows. To fix this I have to implement the I/O manager thread on Windows (I should do this anyway, though). On 03 April 2006 07:38, John Meacham wrote:
however, in a preemptive one, it is less clear whether they may be delivered right away or not and what the implementation costs are, as threads arn't necessarily blocked at a point where they can happily deal with an exception. Perhaps the yhc guys have thought about the problem?
In fact, GHC's SMP mode still doesn't implement throwTo, mainly because it's rather difficult and I need to put some serious thought into how to do it.
there are also a few questions we would want answered for the spec
* do we require the thrower to 'block' until the signal is recieved? (only relevant to pre-emptive implementations)
GHC's throwTo does block until the exception is delivered. The main argument for doing it this way is that you only need an extra forkIO to get the other version. Another argument is that it gives you more guarantees: if two threads throwTo each other, only one will succeed.
* what happens if mutilple thrown exceptions "pile up" before the catcher gets to them?
They get delivered in some order (fairness probably applies in the same way to threads blocked on MVars).
* what happns to exceptions that fall off the end of threads, or the main thread? (should be answered anyway)
throwTo a thread that has completed is a no-op.
* promtness? how much work is the target allowed to do before it "sees" the exception? pthreads allows an implementation to delay processing an exception to a "cancellation point" do we want the same thing in haskell? if not, how will this affect OS threaded implementations?
The only guarantee you can give is "the exception isn't delayed indefinitely, unless the target thread remains inside a block". Just like the fairness property for MVars. Cheers, Simon