This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: [1.7] sigwait bug (SIGCHLD delayed to a next regular signal)
On Mon, Sep 21, 2009 at 08:32:47AM +0000, Waldemar Rachwal wrote:
>Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>>On Sat, Sep 19, 2009 at 10:31:58AM +0000, Waldemar Rachwal wrote:
>>>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,
>>
>>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.
>
>To satisfy the condition (quoted from posix) "action is anything other
>than to ignore", SIGCHLD (and all other signals which default action is
>to ignore) must be setup a handler even if it seems "not useful".
>Being blocked is not sufficient.
Ok. Yes, I was wrong about the meaning of action but, as I said, this
works fine on Linux without setting a dummy handler. The reason for that
is that SIGCHLD is, by default, set to SIG_DFL not SIG_IGN. To quote
from Roland McGrath (one of the glibc maintainers):
"When a signal is set to SIG_IGN, it's true that the signal may be
dropped at generation time and never recorded. But POSIX does not allow
this for signals set to SIG_DFL, even when the default action for the
signal is to ignore it. In this case, the rule when the signal is
blocked is that it must become pending--this allows a sigaction call
before unblocking the signal to change its action."
This comment comes from a bug report which eventually resulted in a fix
to the linux kernel.
>>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.
>
>Completely agree. I hope not to start 3rd thread on the same problem
>anymore (the root cause of the problem from
>http://sourceware.org/ml/cygwin/2009-08/msg00797.html is exactly the
>same as from this thread).
It is not exactly the same since SIGWINCH is special when running in a
console app and will not be delivered reliably.
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