From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9645 invoked by alias); 5 Aug 2017 06:40:22 -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 8214 invoked by uid 89); 5 Aug 2017 06:40:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=unaffected, receipt, mutual X-HELO: mail-qk0-f182.google.com Received: from mail-qk0-f182.google.com (HELO mail-qk0-f182.google.com) (209.85.220.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 Aug 2017 06:40:19 +0000 Received: by mail-qk0-f182.google.com with SMTP id u139so19328494qka.1 for ; Fri, 04 Aug 2017 23:40:19 -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=kKSP5scSZkXTUJzFf0ct+UzCfQboAlpVbeRercsCtzc=; b=p/iO8qYHGLmv9qIuZgXtV3N79UuE8IuouvCu2ez7J3SoKq1X/nOggyf/f0M4r+nWST 6wFJULXT0KM137uTDjiW3yuFPkmbDlrqk7AfUPsm0Qg8mCG34za8czIAXRbEh+R0B3m8 aV9td7PfyV4KvMjSvHUFBvVqQMj6F6p8yN8ZhRFMaAAIr43rU+u72q3aAm1yrFCGZpzr hPQw0rOQMMHqvnfQaDds+l00PeXM75lt2uRakysiNs/9K0KteNal2j/oqg20+r8fYnHP 7JtvUNmIzSiB2V2X70fi1IIgPwl19o7vPxIbiaD42LEhwcyftLUnoVZ8eHL4jJ57EQ4K zPyA== X-Gm-Message-State: AHYfb5j+REbcrL/rnOsqe1lXxqYHssN5sTI0SzyTAdfcQYMpaDDqnNrf rNFcg9RvLcw2Arn0 X-Received: by 10.55.43.144 with SMTP id r16mr6016526qkr.59.1501915218087; Fri, 04 Aug 2017 23:40:18 -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 c46sm2465208qtd.70.2017.08.04.23.40.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Aug 2017 23:40:16 -0700 (PDT) Date: Sat, 05 Aug 2017 06:40:00 -0000 From: Noah Misch To: Kaz Kylheku <920-082-4242@kylheku.com> Cc: cygwin@cygwin.com Subject: Re: Signal delivered while blocked Message-ID: <20170805064013.GA3170154@rfd.leadboat.com> References: <20170804074445.GB3154757@rfd.leadboat.com> <20170804170254.GM25551@calimero.vinschen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg00053.txt.bz2 On Fri, Aug 04, 2017 at 11:58:51AM -0700, Kaz Kylheku wrote: > On 04.08.2017 10:02, Corinna Vinschen wrote: > >On Aug 4 00:44, Noah Misch wrote: > >>The attached demonstration program blocks signals (with sigprocmask()) > >>to > >>achieve mutual exclusion between signal handlers. It aborts upon > >>receipt of a > >>blocked signal. On "CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 > >>x86_64", > >>signals regularly arrive despite being blocked. Essential parts of the > >>program include handling two signal numbers and having handlers run for > >>at > >>least 1-2ms; this problem goes away if I remove one of those > >>attributes. > >>GNU/Linux, AIX, Solaris, and "CYGWIN_NT-6.0 1.7.27(0.271/5/3) > >>2013-12-09 11:57 > >>i686" never deliver a blocked signal to this program. I think this > >>Cygwin > >>behavior is non-conforming. > > > >Thanks for the testcase. I debugged this a while today but the problem > >is far from trivial, apparently. Don't hold your breath for a quick > >solution. Understood. Thanks for studying it. > The test case depends on accesses to the global variable sigblocked not > to be reordered w.r.t. siggprocmask calls. > > It is important that the variable not be set to 1 until after the signals > are > blocked, and be reset to 0 until after they are unblocked. > > Thus, the variable should be declared volatile. Agreed, but ... > Although I would be surprised if this were actually happening ... indeed, that didn't change the result. > Also, related remarks: for the reason that we can't factor out compiler > behavior, with absolute certainty, it would be good to mention not only > the system versions but also GCC. The compiler differs, obviously, > between Cygwin 1.7 and 2.7; not to mention that the case is reported > against i686 of the one, and x86_74 of the other. The Cygwin 2.7 system has gcc-core 5.4.0-1. The unaffected Cygwin 1.7 system has gcc-core 4.8.2-2. -- 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