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