Signals + minimal proposal (was Re: asynchronous exceptions)

Simon Marlow simonmar at microsoft.com
Fri Apr 7 08:29:05 EDT 2006


On 06 April 2006 23:20, John Meacham wrote:

> == on exit ==
> 
> implementations also provide an onExit functionality, for registering
> handlers that can be run when the program exits, as this is the most
> common use of signals as exceptions, to clean up after oneself.
> 
> -- | temporarily register an exit handler for the duration of the
> action argument withExitHandler :: IO () -> IO a -> IO a
> withExitHandler = ....
> 
> -- | register a handler to be run on exiting the program
> onExit :: IO () -> IO ()
> onExit = ....
> 
> -- | block exiting during this call for critical sections.
> blockExit :: IO a -> IO a
> blockExit = ...
> 
> although thees are less powerful than exceptions in that you can only
> catch a single event, "exit" they are more powerful in the sense that
> the exception handlers are global, so when you register an exit
> handler 
> it happens no matter what thread is in scope.
> 
> 
> 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.

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.

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

Cheers,
	Simon


More information about the Haskell-prime mailing list