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)

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

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


Problem reports:
Unsubscribe info:

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