From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9985 invoked by alias); 21 Jun 2008 03:49:04 -0000 Received: (qmail 9977 invoked by uid 22791); 21 Jun 2008 03:49:03 -0000 X-Spam-Check-By: sourceware.org Received: from bender.grapevine.net.au (HELO bender.grapevine.net.au) (203.129.32.139) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 21 Jun 2008 03:48:44 +0000 Received: from localhost (localhost [127.0.0.1]) by bender.grapevine.net.au (Postfix) with ESMTP id 42D3CC02D1 for ; Sat, 21 Jun 2008 13:48:40 +1000 (EST) Received: from bender.grapevine.net.au ([127.0.0.1]) by localhost (bender.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWxvJRe4fid2 for ; Sat, 21 Jun 2008 13:48:40 +1000 (EST) Received: from localhost.localdomain (ppp-187.40.129.203.grapevine.net.au [203.129.40.187]) by bender.grapevine.net.au (Postfix) with ESMTP id 9330BC02C9 for ; Sat, 21 Jun 2008 13:48:39 +1000 (EST) Message-ID: <485C7A15.30803@homemail.com.au> Date: Sat, 21 Jun 2008 03:49:00 -0000 From: Ross Johnson User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: pthreads-win32@sourceware.org Subject: Re: sigaction & pthread_sigmask References: <20080619055744.GA19869@wilbur.25thandClement.com> <485B0ED4.2020909@homemail.com.au> <20080620213916.GA24891@wilbur.25thandClement.com> In-Reply-To: <20080620213916.GA24891@wilbur.25thandClement.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00040.txt.bz2 I'm not qualified to comment in detail. One thing that I can say that may be important for you deciding how much time you put into this is that a lot of effort has gone into keeping the library portable and consistent (for performance) across Windows versions from W95 onward (plus WinCE - or whatever it's called now), and able to be built using at least the MSVC and GNU compilers going back a few years (and others if possible) primarily as a C language library, i.e. without exception handling. Although mildly discouraged, it can be built easily with C++ EH, or SEH (MSVC only). Regards. Ross William Ahern wrote: > 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. > >