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: REVISITED: Signal delivered while blocked

Both testcases confirm that Cygwin _sometimes_ delivers a signal, although
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
shouldn't have.

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

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

"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 practices.
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:
Unsubscribe info:

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