Mail Archives: cygwin/2009/09/19/10:43:39
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
- Raw text -