Signals + minimal proposal (was Re: asynchronous exceptions)

John Meacham john at
Fri Apr 7 08:57:36 EDT 2006

On Fri, Apr 07, 2006 at 01:29:05PM +0100, Simon Marlow wrote:
> > in addition, an exit_ routine should be added that bypasses the exit
> > handlers, quiting the program immediatly.
> I'm not sure I like using exit handlers instead of real exceptions.
> If the exit handler needs access to some shared mutable state, then it
> must be sure that the state is not locked when it gets invoked, so all
> access to the shared state must be protected by blockExit.  So all our
> MVar abstractions will need to use blockExit - but wait, we already use
> Control.Exception.block in GHC for very similar reasons.  And what's
> more, blockExit suffers from the same problems that we solved with block
> and interruptible operations: you need to be interruptible while waiting
> for something (like an MVar), but once it is acquired, the thread should
> not be interruptible until it has established an exception handler to
> release the MVar.

all threads keep running while the exit handers are running, all
blockExit would do is grab and release an MVar. exit itself takes that MVar on
starting to get rid of races to exit as well as protect itsesf from
'blockExit' (but won't ever put the MVar back). 

of course, you have to make sure you don't call 'exit' while holding an
MVar the handler needs, but that is no problem since your signals happen
in their own thread.

the only time you would ever need to use blockExit is when you are
modifying some unprotected resource an exit handler uses, like some
IORefs, even then it strictly isn't necessary because you can just
create an MVar for every such resource, but it is not inconcievable you
might want to block exiting alltogether. in any case, it can be
dropped without affecting utility.

> Exceptions are the right way to handle releasing resources, and they are
> the right way to register cleanup actions.  Therefore I believe
> exceptions are the right way to handle cleaning up on exit, too.

Well, We really need 'onExit' for other reasons as well, I think it
should make it into the standard independently.

I think you have that backwards, releasing resources is the right thing
to do when you get an exception, but there are lots of other reasons you
want to release resources that have nothing to do with exceptions. you
don't use 'throwTo' to close all your files :)

> Since async exceptions are no problem to implement in a coop system,
> shouldn't we use them for exit too?

but then only one thread gets to clean up after itself, and you have the
issue that you can't interrupt a foreign function by throwing to it.

exceptions seem like the right way to handle resource relasing from
synchronous errors, that occur on a specific thread. but not
asynchronous ones, which should not be delivered to any specific thread.
Arranging for all your interesting external resources to be managed by
some specific thread is not very modular.


John Meacham - ⑆⑆john⑈

More information about the Haskell-prime mailing list