Proposal: new signal-handling API

[Bulat Ziganshin]

Hello Brandon,

Monday, July 21, 2008, 10:37:20 AM, you wrote:

>>> 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.

well, is it what i'd in mind - not sure which variant is better:

when main thread creates new thread, it saves its handle. if this
thread creates new one - it does the same again. so when we send
exception to main thread, it can do the same to all its subthreads,
and so that recursive

i've tried to use this model in my program (but not used yet), but not
sure that it will really work and will be helpful


generally speaking, we have an infrastructure of exception handling.
when things go wrong, exception handlers kill files, burn out
documents, so on. when signal arrives that means "things goes wrong"
it will be wise to have opportunity to do the same. MAY BE, we should
have just ability to send some exception to ALL threads in the
program? how about adding to GHC API ability to get full list of
threads?

btw, i have even worse situation - in my program i call
Haskell->C->Haskell and when operation should be terminated it's not
easy to clean up smoothly


-- 
Best regards,
 Bulat                            mailto:Bulat.Ziganshin at gmail.com