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.