I was wondering why System.Posix.Signals is as it is, and whether it could be rewritten to use exceptions, which seems like the obvious way to handle signals. Of course, that requires asynchronous exceptions, but that doesn't seem like a severe problem.

What I currently do is to use the following function

withSig :: Signal -> IO a -> IO a -> IO a withSig s handler job = do id <- myThreadId installHandler s (Catch $ throwDynTo id s) Nothing job `catchDyn` catcher where catcher s' | s' == s = handler catcher s' = throwDyn s'

Hmm, there is clearly a choice between having a signal spawn a new thread or raise an asynchronous exception, and it's not at all clear which is best. But, since we can implement either using the other one, it doesn't really matter too much which one is primitive. I've attached a more robust implementation of your withSig. This one: - doesn't suffer from race conditions around the point at which the signal handler is installed - it uses a datatype for the signal exception (Typeable can be derived these days) - it allows several threads to request notification of the same signal - it doesn't support nesting use of withSig with the same signal. (that could be added, but I'm not sure it's worth it).

Is there any reason all of System.Posix.Signals couldn't be done in this manner? Have the RTS always add a handler for each signal, which just throws an exception. Off the top of my head, all we'd need is one function

acceptSignals :: IO () -- tells RTS to send signal exceptions to this -- thread.

You can implement this too using the module I attached. I guess we should provide this in the POSIX library. Would you like to play around with the API and submit it for inclusion? Cheers, Simon