From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43386 invoked by alias); 20 Aug 2017 16:16:52 -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 25000 invoked by uid 89); 20 Aug 2017 16:16:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=pursue, SUBJECT, Those, $subject X-HELO: mail-pf0-f179.google.com Received: from mail-pf0-f179.google.com (HELO mail-pf0-f179.google.com) (209.85.192.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 20 Aug 2017 16:16:35 +0000 Received: by mail-pf0-f179.google.com with SMTP id w127so9829336pfd.2 for ; Sun, 20 Aug 2017 09:16:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+bR3i8GWROdhyXmZZGmgvzT87Wzo1iiyLlKq6bQwJxA=; b=oC0aj885UCwwJCMgBHSCcpAQDhNG2gawYCnsU8o6yWKxnEL6BQIuu2qpGa9Xww00Qd 26vo856mJ4gSbOjdYR6UNtS/NroJd7lBewGkYi+DEiYGzHNFbM+VaxjLrQ1UxztEk8pW 8+7kT+7yJuJ0Jo3FMvL9i+Q1ymkNeEURh7OdbcXuPKJ2F1Ri7iBLfdaWn1avdYznPYkV QBh8VVy1R5fFR+nV4A1QxYwFULEfK6zFWs8WOAPhAyJLV2swtxb6fbu5lQg37gh5c6Dk bewuAEsCUEvUTHGThRxKuH14s8wix0boHZvfhrhzvZrjyMKnrlCtgyTodAqhni5g7wZN i8cQ== X-Gm-Message-State: AHYfb5jucxJCr5MT59Vo4bgk8c6cmnSR6iinn0t7qSmTY45r+BATBs8t nCOYWZ0bKOVt1lVk X-Received: by 10.98.89.156 with SMTP id k28mr925283pfj.323.1503245794003; Sun, 20 Aug 2017 09:16:34 -0700 (PDT) Received: from rfd.leadboat.com (c-73-158-248-138.hsd1.ca.comcast.net. [73.158.248.138]) by smtp.gmail.com with ESMTPSA id w63sm19614248pfw.28.2017.08.20.09.16.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Aug 2017 09:16:32 -0700 (PDT) Date: Sun, 20 Aug 2017 16:16:00 -0000 From: Noah Misch To: Houder Cc: cygwin@cygwin.com Subject: Re: Signal delivered while blocked Message-ID: <20170820161629.GA4034714@rfd.leadboat.com> References: <20170804074445.GB3154757@rfd.leadboat.com> <8f7f7f8ae098c1321f608645c750cae4@smtp-cloud7.xs4all.net> <20170819080110.GA4022431@rfd.leadboat.com> <873ad91db0845b2dffdc65bf8b1e32a2@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <873ad91db0845b2dffdc65bf8b1e32a2@xs4all.nl> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00181.txt.bz2 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