This is the mail archive of the mailing list for the pthreas-win32 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sigaction & pthread_sigmask

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).


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]