*) What does the "maybe_mask" parameter to System.Posix.Signals.installHandler really do?
It sets the signal mask that will be in effect while generic_handler() in the GHC RTS executes. This is not what we want. [...]
Correct. I think this is a hangup from the days before thread-friendly signal handling, and I didn't think too hard about it when converting the code.
So does that mean we should remove that parameter, or can the signal mask parameter be made to do something useful?
-) Don't use pthread_kill, abolish the pending_handler_buf and use a pipe to send the information from the signal handelr to the scheduler loop.[..]
I like the second option. In fact, I'd like to use the same mechanism
to handle SIGCHLD in the RTS so we can do thread-friendly waiting in the
non-threaded RTS as per discussion on the libraries list recently.
OK, I'll try to implement that when I have time (probably on the weekend). I'll do it in THREADED_RTS only at first, because I'd like to keep the threaded RTS changes in a state where they can be easily merged to the stable branch ( ;-) ).
Cheers,
Wolfgang
_______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
