Rob Arthan wrote:
David, However, while I agree that my "fix" is a hack because it's working around what looks like a bug in the old glibc, I am a little concerned that your signal handling design is not POSIX-conformant. The POSIX specification of sigaction includes the following statement:
"The result of the use of sigaction() and a sigwait() function concurrently within a process on the same signal is unspecified."
I take this to mean that if you change the disposition of a signal using sigaction() while you are waiting for it with sigwait() then the result is unspecified. So the Cygwin behaviour would be conformant. The documentation on signal() doesn't say anything about sigwait(), but it does say:
"Use of this function is unspecified in a multi-threaded process."
I think the POSIX-compliant way of implementing the ML signal function would be to service ML requests to change the disposition of a signal by waking up the signal detection thread and having it call sigaction.
Thanks for pointing this out. I've also had another look at the documentation for sigwait and discovered that the Cygwin behaviour might be acceptable, not because of the interaction with sigaction but because the behaviour of sigwait when a signal is not blocked is undefined.
As a result of all this I've revisited the whole mechanism for signal handling. The difficulty is that the pthread mutex and condition variable functions are not safe when used in a signal handler but it turns out that POSIX sem_post is safe. I've reworked the code to use a signal handler rather than sigwait and this appears to work on all the platforms I've tried, with the inevitable tweaks for the peculiarities of semaphores on Mac OS X and Cygwin.
The new version is in CVS so you can try it out if you wish. I still have to get to the bottom of the other bug.
Regards, David Copied to the mailing list for information.