asynchronous exceptions (was: RE: Concurrency)

[Simon Marlow]

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