Re: Signal delivered while blocked
- Date: Sun, 20 Aug 2017 09:16:29 -0700
- From: Noah Misch <noah@xxxxxxxxxxxx>
- Subject: Re: Signal delivered while blocked
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
> 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"
> "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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple