This is the mail archive of the
mailing list for the Cygwin project.
Re: Signal delivered while blocked
On Fri, Aug 04, 2017 at 11:58:51AM -0700, Kaz Kylheku wrote:
> 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 the
> >>program include handling two signal numbers and having handlers run for
> >>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)
> >>2013-12-09 11:57
> >>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
Understood. Thanks for studying it.
> 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
> blocked, and be reset to 0 until after they are unblocked.
> Thus, the variable should be declared volatile.
Agreed, but ...
> Although I would be surprised if this were actually happening
... indeed, that didn't change the result.
> 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.
The Cygwin 2.7 system has gcc-core 5.4.0-1. The unaffected Cygwin 1.7 system
has gcc-core 4.8.2-2.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple