throwTo & block statements considered harmful

[Cat Dancer]

> The key problem is, at least in the presence of block/unblock, that
> Exceptions are never reliably delivered.

Never?  Even in a function which is in a blocking state?

> The implementation of asynchronous signals, as described by the paper
> "Asynchronous exceptions in Haskell
>     Simon Marlow, Simon Peyton Jones, Andy Moran and John Reppy, PLDI'01."
> is fatally inconsistent with the implementation in GHC 6.4 and GHC 6.6 today.

Is it a goal of the GHC developers to offer an implementation of
asynchronous signals which has the features and benefits described in
the original paper?

If the answer is "no", then there are a couple points...

A: That the current implementation works differently than the original
paper is important to know, and the library documentation should be
updated to clearly describe what the implementation does and does not
do.

B: Since you are programming in a language which doesn't offer the
semantics of the original paper, and you can implement your algorithm
using an event queue... you can go ahead an implement your algorithm
with an event queue.

The situation doesn't rise to the level of "fatal" :-) until you have
an algorithm which you're not able to implement with the facilities
provided by GHC.

For example, if the implementation did not reliably deliver an
asynchronous exception when a function was blocking, then that
probably would be a *fatal* flaw, because then there'd be no way to
break out of a blocking function.

Otherwise, we're talking about convenience.  You'd like asynchronous
signals in GHC to offer the features and benefits described in the
original paper, and that's  a reasonable request to ask for, but it
doesn't rise to the level of a fatal flaw.