asynchronous exceptions (was: RE: Concurrency)

[Simon Marlow]

On 05 April 2006 13:38, John Meacham wrote:

> On Wed, Apr 05, 2006 at 07:47:08AM -0400, David Roundy wrote:
>> For me, asynchronous exceptions are the primary reason to use
>> concurrent Haskell.  They're the only way I'm aware of to write a
>> program that handles signals in Haskell, and it's be a real shame to
>> leave Haskell' programs unable to handle signals--it means that any
>> real-world programs that deal with locking or the like will need to
>> use non-standard extensions.  Unless you can come up with some other
>> way to deal with signals.  Having no chance to clean up when
>> control-C is hit isn't an acceptable alternative, and neither is
>> simply ignoring control-C and forcing users to run kill (and then
>> once again get no chance to clean up!). 
> 
> I have been giving signals some thought, and resarching what other
> languages do, and have a semi-proposal-maybe.

We should be careful here: the Haskell standard has so far remained
platform-independent, and I think it would be nice to keep it that way.


I'm not proposing that we ignore signals, just that we should clearly
delimit the platform-specific bits, perhaps by putting signal support
into an addendum.

> signals tend to be used for one of a couple purposes (some can fall
> into multiple categories):
> 
> signal a synchronous exceptional event - SIGFPE, SIGPIPE, SIGILL,
> SIGSEGV 
> signal an asynchronous exceptional event - SIGINT, SIGHUP
> (interactive) 
> inform the app of an event it might want to take note of -  SIGALRM,
> SIGCHLD, SIGWINCH, SIGHUP (daemon) 
> 
> I think it would make sense to have 3 mechanisms to cover these cases.
> 
> signal a synchronous exceptional event
> - raise a (possibly imprecise) exception on the thread that produced
> the signal. 

GHC has no support for these right now.  They're pretty tricky to
handle, because the OS thread that caused the signal to be raised is
stopped at some arbitrary instruction, and it would require some serious
acrobatics to munge that OS thread into a state where it is possible to
raise the (Haskell) exception.  I do vaguely recall that people have
achieved this in the past, in order to use page faults for write
barriers, that sort of thing.

SIGPIPE is possibly easier than the others.  SIGFPE you can usually turn
off in favour of "exceptional values" instead.

> signal an asynchronous exceptional event
> - the user should be able to choose the threads on which they wish to
>   catch these, those that need to clean up after themselves.
> 
> inform the app of an event it might want to take note of
> - these should run on their own thread, concurrently to all other
>   threads

GHC directly support the latter version, and you can implement the
former with a little extra code and a global variable.  I think it would
be nice to do as you suggest and provide a way to have the async signals
turn directly into exceptions.

One problem, though, is that because we can't interrupt a foreign call
with an async exception, ^C can be rather unresponsive.  Perhaps I
should look into this and see whether it would be possible in GHC for a
concurrent foreign call to be interruptible; it would involve
terminating the foreign call somehow (pthread_cancel?) before raising
the exception.  We can't do this in a bound thread, however.

Cheers,
	Simon