Re: [Haskell-cafe] Re: syscall, sigpause and EINTR on Mac OSX

11 Dec 2005

...
From: Joel Reymont 
To: "Branimir Maksimovic" 
CC: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] Re: syscall, sigpause and EINTR on Mac OSX
Date: Sun, 11 Dec 2005 18:25:47 +0000
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.
After seeing this only I can tell that for example in C++ one can't cout 
clog cerr
or post some event via synchronized event queue or condition variable
from signal handler.
All of that would result in ghosts and goblins in program.
Actually one can't do much at all in signal handlers in multithreaded
environment, cause they don;t like each other.
If you wan;t to trap ^C then I advise that you give up signal handlers
and dedicate one thread to read keyboard events then post
those keyboard events like you do from signal handler.
That is ignore all signals, but fatal ones in which case  you will just
abort program (perhaps try some cleanup, if at all possible from
signal handler)

Hope this helps.

Greetings, Bane.
...
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.
--
http://wagerlabs.com/
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/