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.
_______________________________________________
polyml mailing list
[email protected]
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
