throwTo & block statements considered harmful

[Simon Peyton-Jones]

Chris

It's true that GHC's actual implementation differs from that described in the paper.  The documentation of throwTo already stated that it was synchronous, but failed to mention that this behaviour differs from that described by the paper. I've added a note to the documentation to draw attention to this point.

You are also right to say that GHC does not guaranteed to deliver throwTo at the earliest possible opportunity.  I have documented that behaviour too.  If you and/or others think that's wrong, then do submit a feature request.  It would be quite possible to change the behaviour of 'unblock' to check for pending exceptions.  Perhaps someone would like to implement that and send us a patch?

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-users-bounces at haskell.org]
| On Behalf Of Cat Dancer
| Sent: 08 December 2006 14:01
| To: Chris Kuklewicz
| Cc: GHC Users
| Subject: Re: throwTo & block statements considered harmful
|
| > 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.
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users