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

[Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>]

On Sat, Sep 19, 2009 at 10:31:58AM +0000, Waldemar Rachwal wrote:
>On Fri, Sep 18, 2009 at 04:57:56PM +0000, Waldemar Rachwal wrote:
>>Apparently, signals like SIGWINCH and SIGCHLD, which are a little bit
>>special, need to be kicked by other signal to be eventually returned by
>>sigwait().
>>
>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.

I was explaining the problem to you.  As I said, SIGCHLD is a signal
like any other signal and if you had tried to use a similar mechanism to
trap, say, SIGINT, you would have seen the same problem.

>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.

Since the "above" never mentioned the word handler, I don't see how your
point is valid.  blocked != handler.  blocked == sigprocmask or some
similar mechanism.  You did use sigprocmask in your example.  Setting
the handler doesn't seem to serve any useful purpose since it isn't
being used.  I tested this on linux just to be sure.  Actually, on some
versions of linux you don't even have to block the signal first.

In any event, you provided a test case, I provided a fix.  That's the
desired outcome.  Arguing about this is pointless unless the fix didn't
actually fix anything.

cgf

--
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