Understood. But I'm printing things in the signal handler to show that it was triggered. And I trigger it when ^C is pressed (well, one more signal): initSnippets :: IO () initSnippets = do initSSL installHandler sigPIPE Ignore Nothing flip mapM_ [sigTERM, sigINT] $ \sig -> do installHandler sig (handler sig) Nothing where handler sig = Catch $ do trace_ $ "Signal " ++ show sig + + " caught." trace_ "Broadcasting Quit..." broadcast (ForcedQuit :: Event ()) This way I know what the signal was that triggered the handler and I can tell that it was triggered. The deadlock is somewhere else because the handler is not being tripped. The issue of the signal handler being tripped by a phantom ^C (signal 2) is another issue entirely. On Dec 11, 2005, at 6:10 PM, Branimir Maksimovic wrote:
Though I frorgot to add that deadlock can be caused by signal somewhere else (eg other thread) if signal handler eg locks mutex internally or calls some other non asynchronous safe functions like locking functions. This is likely scenario, if you doubt at signal handlers but I don;t know the details . Deadlocks can be caused by other things, not neccessarily signals.