This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: Signal delivered while blocked
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