Proposal: new signal-handling API

[Duncan Coutts]

On Mon, 2008-07-21 at 02:37 -0400, Brandon S. Allbery KF8NH wrote:
> On 2008 Jul 21, at 2:20, Bulat Ziganshin wrote:
> > Monday, July 21, 2008, 7:58:07 AM, you wrote:
> >>> [Stuff about doing signals as exceptions.]
> >
> >> I think that the issue with this is, to which threads do you  
> >> deliver the
> >> exceptions?
> >
> > main one. it should handle other threads as needed
> 
> 
> I'm not so sure:  if the point is to release resources on signal, you  
> want to deliver the exception to (potentially) all threads, and the  
> main thread may not have any idea of the needs of the library being  
> used by another thread.
> 
> I think I would handle these exceptions by sending them only to  
> threads which have registered an interest (withSignalException sigMask  
> $ do ... :: Either SignalException a).  If a SignalException somehow  
> ends up being rethrown back to the runtime, this is likely to be an  
> error which should cause program termination --- but I can also see it  
> being quietly ignored,  This might be a +RTS option.

And that was my point. That this issue of cleaning up when the program
is about to die is a good deal more general than signals or even posix.
Currently libs that launch threads have no easy means of getting
notified when the main thread is going to exit. This is just as true for
exitWith as for posix signals.

One can use a withLib function but even that's not easy if not all the
libs threads are going to be launched then and there. withLib would have
to save some MVar collection of threads and other threads the lib
launched would have to be added/removed from the set. Then withLib would
send exceptions to all the threads in it's collection.

My intuition is that we should look at what erlang does. As I understand
it they have something which allows them to tie threads such that when
one dies the other dies.

Duncan