Signal delivered while blocked

[Kaz Kylheku]

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()) 
>> to
>> 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 
>> x86_64",
>> signals regularly arrive despite being blocked.  Essential parts of 
>> the
>> program include handling two signal numbers and having handlers run 
>> for at
>> least 1-2ms; this problem goes away if I remove one of those 
>> attributes.
>> GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) 
>> 2013-12-09 11:57
>> i686" never deliver a blocked signal to this program.  I think this 
>> Cygwin
>> 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
> solution.

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 
signals are
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 
principle
at least, compiler could be too clever and "just know" that the 
sigprocmask
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.

Cheers ...

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