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:mime-version:content-type
	:content-transfer-encoding:date:from:to:cc:subject:in-reply-to
	:references:message-id; q=dns; s=default; b=HQeuSVAhOBqDs/6SntcK
	r3ZeiXpnuobYeAdjbuAEDzdOwzDLsznRJ6E9qUlxviulC4A3vxD7C+KCdUQULWuH
	CV6NEQ7BlS9ZYPEhWobgCZu6MbtoRgUBJkyBko0reHigelDoCDVKB7cDyiT0x58U
	bZzU5KueByM0RHhrRVIzw1Q=
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:mime-version:content-type
	:content-transfer-encoding:date:from:to:cc:subject:in-reply-to
	:references:message-id; s=default; bh=EYWsKZB8OALIVvBMXoQ4Cnjn4J
	c=; b=h76TRnV9WH0nAwufFxSyFhqXBBUs2TnxsbtjoDKFAiUSDHoy+5gdcAEGzK
	/d/vUFvqEzZd/e36JPtUbZr/ow4OcJxIWbna3HmFO2pfswWjCyBhOlMrCauhMawU
	CaGJ3Xa/6gx3tTRjwmGGZdHCXJIyTQ/ERvzJLj1iGsJe6j6K8=
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=-0.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=astonished, genius, contextual, H*RU:206
X-HELO:	lb1-smtp-cloud8.xs4all.net
MIME-Version:	1.0
Date:	Sun, 20 Aug 2017 14:18:45 +0200
From:	Houder <houder AT xs4all DOT nl>
To:	Noah Misch <noah AT leadboat DOT com>
Cc:	cygwin AT cygwin DOT com
Subject:	Re: Signal delivered while blocked
In-Reply-To:	<20170819080110.GA4022431@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>
Message-ID:	<873ad91db0845b2dffdc65bf8b1e32a2@xs4all.nl>
X-Sender:	houder AT xs4all DOT nl
User-Agent:	XS4ALL Webmail
X-CMAE-Envelope:	MS4wfEYzH+xbK+2oTZTOL185aEVaEuIWBankWCWYm46QVd4rH7EuGClcrtLKyMlLaFR703SXsLZar5WgzzgnNZPYzRJb7D2ar0CK9mFuKjx4mP5+l/wHm1vz J44NvCafnK8yMfZtlja2aT4F2C4RTCZov7eT1OFWesOROPAeZGe9gZ1smyhmKkbW5FLXO2n91m18MZ2M5S+BsGyVsi1hUgjzzGVG1YNuejwbNzRr5YoUxSvP

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:

Noah,

My apologies! My command over the English language is poor. English is 
not
my native tongue, and I have hard time getting my point across in 
English.

I am not a language genius.

Let me try again with regard to the most important thing.

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.

And yes, the above should be present in a text book about U/Linux (and 
yes,
it is not explicitly stated in LPI).

Regards,

Henri

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