Re: sigaction & pthread_sigmask

[William Ahern <william@25thandClement.com>]

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.