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: 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()) 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


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