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@gmail.com