Re: Signal delivered while blocked
- Date: Fri, 04 Aug 2017 11:58:51 -0700
- From: Kaz Kylheku <920-082-4242@xxxxxxxxxxx>
- Subject: Re: Signal delivered while blocked
On 04.08.2017 10:02, Corinna Vinschen wrote:
On Aug 4 00:44, Noah Misch wrote:
The attached demonstration program blocks signals (with sigprocmask())
achieve mutual exclusion between signal handlers. It aborts upon
receipt of a
blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18
signals regularly arrive despite being blocked. Essential parts of
program include handling two signal numbers and having handlers run
least 1-2ms; this problem goes away if I remove one of those
GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3)
i686" never deliver a blocked signal to this program. I think this
behavior is non-conforming.
Thanks for the testcase. I debugged this a while today but the problem
is far from trivial, apparently. Don't hold your breath for a quick
Hi! It seems I haven't grasped at straws in a few weeks, so I'm
eager to tug on some dry turf. What the hay, you know?
The test case depends on accesses to the global variable sigblocked not
to be reordered w.r.t. siggprocmask calls.
It is important that the variable not be set to 1 until after the
blocked, and be reset to 0 until after they are unblocked.
Thus, the variable should be declared volatile.
(Even basic ISO C says that variables modified by signal handlers
shall be of type "volatile sig_atomic_t", not just "atomic_t").
Although I would be surprised if this were actually happening, in
at least, compiler could be too clever and "just know" that the
standard library function has no interactions with a user-defined global
variable and so the order of the call with respect to the manipulation
of that variable doesn't matter.
Also, related remarks: for the reason that we can't factor out compiler
behavior, with absolute certainty, it would be good to mention not only
the system versions but also GCC. The compiler differs, obviously,
between Cygwin 1.7 and 2.7; not to mention that the case is reported
against i686 of the one, and x86_74 of the other.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple