X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:subject:mime-version:content-type
	:content-transfer-encoding:date:from:in-reply-to:references
	:message-id; q=dns; s=default; b=IZBoMRPZ+Y0uBMrm6XX4CrGsgdymTJL
	1DE3z90MvzLNFhA7ARurZ4PPqa0tYGO0/0MmC6ydQQzrVgfqROIxTBmIlzvdT+2b
	jTvJyzd3agCVmD3S134x8J6JiGsydRLbz4RCdai3xdhBRfp/+dbeX+yeUbdYhjrG
	Ea6KEyKwY+DI=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:subject:mime-version:content-type
	:content-transfer-encoding:date:from:in-reply-to:references
	:message-id; s=default; bh=QpfNI0+kq3BqksxOwd4++Fso/to=; b=Lcxdc
	VJVj4WjjhQdY96rwNY+HCuX7eMPxPc8eqrBEoNuK5wPOH6LE0ASHDfmvEMNIozsa
	psJKIzd0zUDQ3/zJaMK4UdHLfPC+L0bGJzoOyiEKfzg4O6UCiGx6AOgKR2Mrvauj
	fILIYwPIbml8EbqZpCCc8OG4E6Og4ZpFpuU2uo=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FROM_STARTS_WITH_NUMS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:4.72, Hx-languages-length:2182, Hx-spam-relays-external:sk:smtp-ou, H*RU:sk:smtp-ou
X-HELO:	smtp-out-no.shaw.ca
X-Authority-Analysis:	v=2.2 cv=HahkdmM8 c=1 sm=1 tr=0 a=95A0EdhkF1LMGt25d7h1IQ==:117 a=95A0EdhkF1LMGt25d7h1IQ==:17 a=IkcTkHD0fZMA:10 a=SMorJkV_YP8A:10 a=KeKAF7QvOSUA:10 a=iz5CbBhvdRgm990WNzcA:9 a=QEXdDO2ut3YA:10
To:	cygwin AT cygwin DOT com
Subject:	Re: Signal delivered while blocked
X-PHP-Originating-Script:	501:rcmail.php
MIME-Version:	1.0
Date:	Fri, 04 Aug 2017 11:58:51 -0700
From:	Kaz Kylheku <920-082-4242 AT kylheku DOT com>
In-Reply-To:	<20170804170254.GM25551@calimero.vinschen.de>
References:	<20170804074445 DOT GB3154757 AT rfd DOT leadboat DOT com> <20170804170254 DOT GM25551 AT calimero DOT vinschen DOT de>
Message-ID:	<aa14e8b0af5a6808963604f2f263eaa1@mail.kylheku.com>
X-Sender:	920-082-4242 AT kylheku DOT com
User-Agent:	Roundcube Webmail/0.9.2
X-CMAE-Envelope:	MS4wfFiiEokUPEqPpJI0aT2TUMyBkklkRQclNYrd5XMLgvIUXqFa0Iyb6rXvA+ImWOSsh3MKqyp9fGq5fAfyEbb0zxRCQw3wnRhLtY891Jy9d7ChIcdIhBwB eWU0Eb50voj416aFfddzzE1DHh7+7KtKv2esP8I+Q6m669+wqJ/RYfw0
X-IsSubscribed:	yes
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id v74IxBmj023580

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

- Raw text -