This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Christopher Faylor <cgf-use-the-mailinglist-please <at>> 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:

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.

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

> 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
> This will be fixed in the next snapshot.


Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]