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=Je/U
	08I53DEeyWa/JJmmqt2alpG9vSd8pqyTZERSdm92ckQ+dJSViX3I853Z4h9+H8te
	6TSkBwyxQtWNdWB8Y+dKAuXM6Uvbv5kJnkvukJ7xf2267DweUggxI+AGZyiPVJwH
	I7YB9wBvTD3aRg+2jXwNcxsObiWTGpZSeSHsWR0=
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=rUseOGr+Yh
	Ly6bblt6ZJROa389Q=; b=lwpLF1X/mvPSxV8HF2wE6Zz4K/uyZd1GBjrbZctRK+
	U43OLa5dllKY8upRdmw5WAxaCObp+tbmvaxu6+cd2ipdJbLGR9BTOeiTBfjsOtVV
	lyw4N3QOL63B1JcXDKsnfWCbOYcKkxMHtCXv2+OxGDGk9TCjwgUVN63P6H0GolKO
	w=
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.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=pursue, SUBJECT, Those, $subject
X-HELO: mail-pf0-f179.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=+bR3i8GWROdhyXmZZGmgvzT87Wzo1iiyLlKq6bQwJxA=;        b=oC0aj885UCwwJCMgBHSCcpAQDhNG2gawYCnsU8o6yWKxnEL6BQIuu2qpGa9Xww00Qd         26vo856mJ4gSbOjdYR6UNtS/NroJd7lBewGkYi+DEiYGzHNFbM+VaxjLrQ1UxztEk8pW         8+7kT+7yJuJ0Jo3FMvL9i+Q1ymkNeEURh7OdbcXuPKJ2F1Ri7iBLfdaWn1avdYznPYkV         QBh8VVy1R5fFR+nV4A1QxYwFULEfK6zFWs8WOAPhAyJLV2swtxb6fbu5lQg37gh5c6Dk         bewuAEsCUEvUTHGThRxKuH14s8wix0boHZvfhrhzvZrjyMKnrlCtgyTodAqhni5g7wZN         i8cQ==
X-Gm-Message-State: AHYfb5jucxJCr5MT59Vo4bgk8c6cmnSR6iinn0t7qSmTY45r+BATBs8t	nCOYWZ0bKOVt1lVk
X-Received: by 10.98.89.156 with SMTP id k28mr925283pfj.323.1503245794003;        Sun, 20 Aug 2017 09:16:34 -0700 (PDT)
Date: Sun, 20 Aug 2017 09:16:29 -0700
From: Noah Misch <noah AT leadboat DOT com>
To: Houder <houder AT xs4all DOT nl>
Cc: cygwin AT cygwin DOT com
Subject: Re: Signal delivered while blocked
Message-ID: <20170820161629.GA4034714@rfd.leadboat.com>
References: <20170804074445 DOT GB3154757 AT rfd DOT leadboat DOT com> <8f7f7f8ae098c1321f608645c750cae4 AT smtp-cloud7 DOT xs4all DOT net> <20170819080110 DOT GA4022431 AT rfd DOT leadboat DOT com> <873ad91db0845b2dffdc65bf8b1e32a2 AT xs4all DOT nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <873ad91db0845b2dffdc65bf8b1e32a2@xs4all.nl>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-IsSubscribed: yes

On Sun, Aug 20, 2017 at 02:18:45PM +0200, Houder wrote:
> On 2017-08-19 10:01, Noah Misch wrote:
> >What words in those chapters prompted your conclusion?  I see nothing in
> >20.10 or 20.13 about contextual restrictions on SIG_SETMASK.  Posix
> >mentions no such restrictions in its sigprocmask() page, and Posix does
> >say:

> Keep in mind, that I replied to your post after I had executed your code on
> Linux (and had a hard look at your code).
> 
> I was astonished to see the 'run-away' stack on Linux ...
> 
> ("that cannot be correct", was my thinking)
> 
> I should have written in my previous reply:
> 
>     "you cannot make use of SIG_SETMASK in sigprocmask() within the context
>      of a handler", IN THE WAY YOU DO IT"
> or
>     "in the body of a signal handler, one cannot modify the signal mask w/o
>      knowing what it was at the beginning"
> 
>  1. when a signal handler is entered, the kernel will (usually) have added
>     the signal number, associated to the handler, to the mask
>  2. the execution of a handler may be nested within the execution of another
> 
> Consequently, one does not know what the signal mask is at the beginning of
> the critical section in the handler.
> 
> That is why you want to save the current signal mask when modifying it (at
> the start of the critical section).
> 
> At the end of the critical section, one should restore the old signal mask,
> or test it in case one want to revert the signal mask "by hand".
> 
> Take a look at listing 20-5 in LPI.

If the test program has undefined behavior according to Posix, I want to know
that.  If the test program can cause $SUBJECT according to Posix, I want to
know that.

Following your advice above would not remove undefined behavior or prevent
$SUBJECT.  It would make the signal-using software more maintainable and
reduce the risk of consuming all stack space.  Those are good goals for
authors to pursue, but this thread is about delivery of blocked signals.

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