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:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:in-reply-to; q=dns; s=default; b=hOAR
	IfpyBSBCdWvtm3WU1S1hS49a4CbO3myJzZAdK/1HvqNdwPfgGKfMfzHQx0CX6/t8
	NWCg+kT53QMZXIDmKK2bWs/2iHjDBgSnlR1SkyzNyoyFc+Sb3KKotFdloPdpka+u
	2mSxmmL3lLKRyWIGF0e6RE0XRdj5EoJwMdf1XBY=
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:date:from:to:cc:subject:message-id:references
	:mime-version:content-type:in-reply-to; s=default; bh=h6q4G9tLOh
	290xZqKXcHOSgtTaE=; b=hAceZJhmGA0vtQy215bcQ05JsbUwXU0sfPuMTuGpPF
	rG99jffnGpZ7cRcguGHDy2LLuTuE+D/CytAjOo7TZANog06KmEYO0FGb6UYHYvYG
	MD66/TtQYN4Jy5LWRPka8ePARSyJt3G+FKrFToxaPvkL9UoDveD14ZqYN19ltL4O
	Q=
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.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=unaffected, receipt, mutual
X-HELO: mail-qk0-f182.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:date:from:to:cc:subject:message-id:references         :mime-version:content-disposition:in-reply-to:user-agent;        bh=kKSP5scSZkXTUJzFf0ct+UzCfQboAlpVbeRercsCtzc=;        b=p/iO8qYHGLmv9qIuZgXtV3N79UuE8IuouvCu2ez7J3SoKq1X/nOggyf/f0M4r+nWST         6wFJULXT0KM137uTDjiW3yuFPkmbDlrqk7AfUPsm0Qg8mCG34za8czIAXRbEh+R0B3m8         aV9td7PfyV4KvMjSvHUFBvVqQMj6F6p8yN8ZhRFMaAAIr43rU+u72q3aAm1yrFCGZpzr         hPQw0rOQMMHqvnfQaDds+l00PeXM75lt2uRakysiNs/9K0KteNal2j/oqg20+r8fYnHP         7JtvUNmIzSiB2V2X70fi1IIgPwl19o7vPxIbiaD42LEhwcyftLUnoVZ8eHL4jJ57EQ4K         zPyA==
X-Gm-Message-State: AHYfb5j+REbcrL/rnOsqe1lXxqYHssN5sTI0SzyTAdfcQYMpaDDqnNrf	rNFcg9RvLcw2Arn0
X-Received: by 10.55.43.144 with SMTP id r16mr6016526qkr.59.1501915218087;        Fri, 04 Aug 2017 23:40:18 -0700 (PDT)
Date: Fri, 4 Aug 2017 23:40:13 -0700
From: Noah Misch <noah AT leadboat DOT com>
To: Kaz Kylheku <920-082-4242 AT kylheku DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: Signal delivered while blocked
Message-ID: <20170805064013.GA3170154@rfd.leadboat.com>
References: <20170804074445 DOT GB3154757 AT rfd DOT leadboat DOT com> <20170804170254 DOT GM25551 AT calimero DOT vinschen DOT de> <aa14e8b0af5a6808963604f2f263eaa1 AT mail DOT kylheku DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aa14e8b0af5a6808963604f2f263eaa1@mail.kylheku.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-IsSubscribed: yes

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

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
> are
> 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
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple