Signal Handling Woes

[Wolfgang Thaller]

>> *) 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