Re: REVISITED: Signal delivered while blocked
- Date: Sun, 20 Aug 2017 08:44:10 -0700
- From: Kaz Kylheku <920-082-4242@xxxxxxxxxxx>
- Subject: Re: REVISITED: Signal delivered while blocked
Both testcases confirm that Cygwin _sometimes_ delivers a signal,
the signal mask specifies (verified by the test case) it should not.
Hence, your fixes are not relevant to the issue.
However, they also demonstrate that the signal nesting (at least,
self-esting: the same signal being handled more than once)
is also not relevant to the issue.
Eliminating unlimited nesting can be regarded as an improvement
to the test case, since it doesn't have to worry about hitting
a stack depth limit.
The original test case is simple in that it uses precisely one known
signal mask for blocking the signals, and another one for unblocking
them. So it it is easy to see that the signal went off when it
This global clobbering of the signal mask leads to the nesting
because, for instance, when the SIGCHLD signal is running,
before it has reached the sigforbid() call, the SIGUSR1 signal
handler can go off. That handler will finish by calling sigpermit()
which will unblock not only SIGUSR1 but also SIGCHLD. So control
returns to the SIGCHLD handler, and SIGCHLD is now unblocked,
opening the door to nesting of that signal. Another window for this
to happen is after the SIGCHLD has itself called sigpermit(),
as the last step before returning.
You're not correct in insinuating that POSIX forbids such a
Such a manipulation is merely a bad idea; it is not good application
practice for a signal handler to clobber the mask bits belonging to
"We wouldn't do this in a real program" isn't the same
as "POSIX doesn't define it".
It's perfectly okay for API test programs to deviate from best
If that is necessary to make a problem easier to reproduce, or
to simplify the test case, then it should be done that way.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple