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:cc:in-reply-to:references
	:message-id; q=dns; s=default; b=ViI+ZzP2LlasflRk9ZRFkRO2b/dnFJf
	t7ajobcOklCLxLMv08pTEj1oQA8GrFBIEzXGwJVXiB5ivK/pbApo+n+NCCBASI61
	dVlcG/w5ki/5/0/SUPzzjnGXc21fNJNYm6YsWRG+wHXsedy2lMXRUnzdVvuE9fjT
	7a9s6kxzKdh0=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
To: Houder <houder AT xs4all DOT nl>
Subject: Re: REVISITED: Signal delivered while blocked
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Date: Sun, 20 Aug 2017 08:44:10 -0700
From: Kaz Kylheku <920-082-4242 AT kylheku DOT com>
Cc: Cygwin <cygwin AT cygwin DOT com>
In-Reply-To: <c05c742f0f3809e6d1afb8fb2c646ad7@xs4all.nl>
References: <c05c742f0f3809e6d1afb8fb2c646ad7 AT xs4all DOT nl>
Message-ID: <acd9f0489f1c829f084d3198cecb80e7@mail.kylheku.com>
User-Agent: Roundcube Webmail/0.9.2
Content-Transfer-Encoding: 8bit

> Both testcases confirm that Cygwin _sometimes_ delivers a signal, 
> although
> the signal mask specifies (verified by the test case) it should not.

Hence, your fixes are not relevant to the issue.

However, they also demonstrate that the signal nesting (at least,
self-esting: the same signal being handled more than once)
is also not relevant to the issue.

Eliminating unlimited nesting can be regarded as an improvement
to the test case, since it doesn't have to worry about hitting
a stack depth limit.

The original test case is simple in that it uses precisely one known
signal mask for blocking the signals, and another one for unblocking
them. So it it is easy to see that the signal went off when it
shouldn't have.

This global clobbering of the signal mask leads to the nesting
because, for instance, when the SIGCHLD signal is running,
before it has reached the  sigforbid() call, the SIGUSR1 signal
handler can go off. That handler will finish by calling sigpermit()
which will unblock not only SIGUSR1 but also SIGCHLD. So control
returns to the SIGCHLD handler, and SIGCHLD is now unblocked,
opening the door to nesting of that signal. Another window for this
to happen is after the SIGCHLD has itself called sigpermit(),
as the last step before returning.

You're not correct in insinuating that POSIX forbids such a 
manipulation.

Such a manipulation is merely a bad idea; it is not good application
practice for a signal handler to clobber the mask bits belonging to
other signals.

"We wouldn't do this in a real program" isn't the same
as "POSIX doesn't define it".

It's perfectly okay for API test programs to deviate from best 
practices.
If that is necessary to make a problem easier to reproduce, or
to simplify the test case, then it should be done that way.


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