[1.7] sigwait bug (SIGCHLD delayed to a next regular signal)

[Waldemar Rachwal]

Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:

> 
> Thanks for the test case.  The problem has nothing to do with anything
> "special" about SIGCHLD.  It's a signal like any other signal.
> 

I am not sure it's clear. With regard to sigwait() SIGCHLD like any other signal
must not only be blocked, additionally like any other signal it cannot be
ignored, which is not common as only few signals are ignored by default,
and SIGCHLD and SIGWINCH are in this group.

POSIX is explicit here:

http://www.opengroup.org/onlinepubs/9699919799/

<quote>
2.4.1 Signal Generation and Delivery

However, a signal can be "blocked" from delivery to a thread.

If the action associated with a blocked signal is anything other than to
ignore the signal, and if that signal is generated for the thread,

the signal shall remain pending until

it is unblocked,

it is accepted when it is selected and returned by a call to the
sigwait() function,

or the action associated with it is set to ignore the signal.
</quote>

Simply a signal must be blocked and (actually) not ignored to be processed by
sigwait().

> Cygwin was not performing sigwait() processing if there was a handler
> set up for the signal.  Your test case would have worked if you had not
> set up a dummy handler.
>

As stated above a handler is the must, otherwise the test won't work under POSIX
systems.
 
> This will be fixed in the next snapshot.
>  

Thanks,
Waldemar.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple