Re: Signal delivered while blocked

[Noah Misch <noah@leadboat.com>]

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