From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10805 invoked by alias); 20 Jun 2008 21:39:41 -0000 Received: (qmail 10797 invoked by uid 22791); 20 Jun 2008 21:39:41 -0000 X-Spam-Check-By: sourceware.org Received: from wilbur.25thandClement.com (HELO wilbur.25thandClement.com) (208.96.11.245) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Jun 2008 21:39:23 +0000 Received: from wilbur.25thandClement.com (william@localhost.25thandClement.com [127.0.0.1]) by wilbur.25thandClement.com (8.14.0/8.13.8) with ESMTP id m5KLdH6J024737 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Jun 2008 14:39:17 -0700 (PDT) Received: (from william@localhost) by wilbur.25thandClement.com (8.14.0/8.14.0/Submit) id m5KLdGJ0029401; Fri, 20 Jun 2008 14:39:16 -0700 (PDT) Date: Fri, 20 Jun 2008 21:39:00 -0000 From: William Ahern To: Ross Johnson Cc: pthreads-win32@sourceware.org Subject: Re: sigaction & pthread_sigmask Message-ID: <20080620213916.GA24891@wilbur.25thandClement.com> References: <20080619055744.GA19869@wilbur.25thandClement.com> <485B0ED4.2020909@homemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485B0ED4.2020909@homemail.com.au> User-Agent: Mutt/1.4.2.3i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (wilbur.25thandClement.com [127.0.0.1]); Fri, 20 Jun 2008 14:39:17 -0700 (PDT) X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2008/txt/msg00039.txt.bz2 On Fri, Jun 20, 2008 at 11:58:44AM +1000, Ross Johnson wrote: > Please submit the patch. Send it to me directly if it's large and I will > put it up on the FTP site for others to review if they wish. > I punted on per-thread masks (and thus capabilities for pthread_kill(), as well) because of my particular time constraints in my current project. I just wanted to be able to call sigwait(). Any advice on safely using thread-local storage, or tolerance for caveats? I'm concerned about the interrupts arriving before thread-local storage can be initialized (using the API, as opposed to linker capabilities, the latter of which I doubt solves the race anyhow). I had initially set out to use STM (Software Transactional Memory), but my subsequent understanding of the literature has been that CAS cannot support fixed space STM algorithms (as opposed to strong LL/SC primitives, which don't exist in the real-world), but rather require space linear to the number of processes/threads, and thus dynamic memory. Clearly this poses a problem for async-safety (honestly, I have no time to try to make DCAS work, and in any event it would fail on early AMD 64-bit processors, which have no 128-bit CAS operations, and anything less than 32-bit versioning--because pointers would eat 48 out of 64 bits--isn't exactly a strong solution to the ABA problem.) I'm inclined to simply document that interrupts which arrive before TLS can be setup are discarded, and so simply try to grab any per-thread signal mask from the pthread_t object (I'll need to confirm that TlsGetValue is lock-free, of course, or make other arrangements). I'm entirely fuzzy on Microsoft SEH in general, so perhaps there are stronger constraints I can rely on. (My signal delivery always serializes handler execution, so handler masks are moot; I wonder if SEH guarantees that anyhow.) Also, I'll need time to recode my atomic operations and implementations according to the local code base (including writing ptw32_InterlockedCompareExchange64; currently I'm using GCC 4.1 intrinsics). I'll aim for a proper patch by the end of the month or early July. I just wanted confirmation my time wouldn't necessarily be wasted.