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

[Branimir Maksimovic]

>From: Joel Reymont <joelr1 at gmail.com>
>To: "Branimir Maksimovic" <bmaxa at hotmail.com>
>CC: haskell-cafe at 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/