From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68218 invoked by alias); 20 Aug 2017 12:18:53 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 68126 invoked by uid 89); 20 Aug 2017 12:18:50 -0000 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 Received: from lb1-smtp-cloud8.xs4all.net (HELO lb1-smtp-cloud8.xs4all.net) (194.109.24.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 20 Aug 2017 12:18:48 +0000 Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:206]) by smtp-cloud8.xs4all.net with ESMTPA id jPBldTisOcQyLjPBldW5yO; Sun, 20 Aug 2017 14:18:46 +0200 Received: from a83-162-234-136.adsl.xs4all.nl ([83.162.234.136]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Sun, 20 Aug 2017 14:18:45 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 20 Aug 2017 12:18:00 -0000 From: Houder To: Noah Misch Cc: cygwin@cygwin.com Subject: Re: Signal delivered while blocked In-Reply-To: <20170819080110.GA4022431@rfd.leadboat.com> References: <20170804074445.GB3154757@rfd.leadboat.com> <8f7f7f8ae098c1321f608645c750cae4@smtp-cloud7.xs4all.net> <20170819080110.GA4022431@rfd.leadboat.com> Message-ID: <873ad91db0845b2dffdc65bf8b1e32a2@xs4all.nl> X-Sender: houder@xs4all.nl User-Agent: XS4ALL Webmail X-CMAE-Envelope: MS4wfEYzH+xbK+2oTZTOL185aEVaEuIWBankWCWYm46QVd4rH7EuGClcrtLKyMlLaFR703SXsLZar5WgzzgnNZPYzRJb7D2ar0CK9mFuKjx4mP5+l/wHm1vz J44NvCafnK8yMfZtlja2aT4F2C4RTCZov7eT1OFWesOROPAeZGe9gZ1smyhmKkbW5FLXO2n91m18MZ2M5S+BsGyVsi1hUgjzzGVG1YNuejwbNzRr5YoUxSvP X-SW-Source: 2017-08/txt/msg00177.txt.bz2 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