Re: sigaction & pthread_sigmask

[Ross Johnson <Ross.Johnson@homemail.com.au>]

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:
> <snip>
>   
>> 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.
>
>