public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Kaz Kylheku <920-082-4242@kylheku.com>
To: Houder <houder@xs4all.nl>
Cc: Cygwin <cygwin@cygwin.com>
Subject: Re: REVISITED: Signal delivered while blocked
Date: Sun, 20 Aug 2017 15:44:00 -0000	[thread overview]
Message-ID: <acd9f0489f1c829f084d3198cecb80e7@mail.kylheku.com> (raw)
In-Reply-To: <c05c742f0f3809e6d1afb8fb2c646ad7@xs4all.nl>

> 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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

      parent reply	other threads:[~2017-08-20 15:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-16 21:22 Houder
2017-08-18 16:20 ` Corinna Vinschen
2017-08-20 13:20   ` Houder
2017-08-20 12:59 ` Houder
2017-08-20 15:44 ` Kaz Kylheku [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acd9f0489f1c829f084d3198cecb80e7@mail.kylheku.com \
    --to=920-082-4242@kylheku.com \
    --cc=cygwin@cygwin.com \
    --cc=houder@xs4all.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).