This is the mail archive of the
mailing list for the Cygwin project.
Re: [1.7] sigwait bug (SIGCHLD delayed to a next regular signal)
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin at cygwin dot com
- Date: Fri, 18 Sep 2009 17:35:22 -0400
- Subject: Re: [1.7] sigwait bug (SIGCHLD delayed to a next regular signal)
- References: <loom.20090918T184921firstname.lastname@example.org>
- Reply-to: cygwin at cygwin dot com
On Fri, Sep 18, 2009 at 04:57:56PM +0000, Waldemar Rachwal wrote:
>A problem seems very close to one described in
>and now I don't think it can be easily explained by
>"limitation in Cygwin's implementation of SIGWINCH".
>What I did this time...
>When I fork children and next observe their termination in
>the parent process by means of sigwait(),
>*none* of the SIGCHLD signals is returned immediately until some other
>"regular" signal, let's say SIGINT, is sent to the parent.
>Apparently, signals like SIGWINCH and SIGCHLD, which are a little bit
>special, need to be kicked by other signal to be eventually returned by
>What makes these signals "special" is that their default action is `to
>IGNORE' and to be useful for sigwait() they need to register some dummy
>Maybe this has something to do why sigwait() doesn't work as
Thanks for the test case. The problem has nothing to do with anything
"special" about SIGCHLD. It's a signal like any other signal.
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.
This will be fixed in the next snapshot.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple