Skip Menu |

Subject: need feature tests for deciding when to use pthread code
Download (untitled) / with headers
text/plain 1.8KiB
The fix I put in for ticket 5560 tests for the OS name and version to decide whether to use
the pthread support unconditionally. (The thread library exists, but just re-points us to the
support in libc that's available anyways.) There are also checks for AIX and Tru64 that turn
on the thread support unconditionally. (I believe on both systems we don't get any stub
versions in libc, and we don't get weak references. On AIX, though, I think we get the thread
library loaded in when dlopen is used, so dynamically loaded code can use thread support.)

Proper feature tests should probably be worked out for these cases, so that other systems
with similar attributes can avoid the run-time conditional tests and just call the pthread
routines directly.

The annoying part of this is probably going to be figuring out what the right properties are
that we want to test for.

In the Solaris case -- pthread support available in libc -- the thread support functions
should be available and the mutex and once functionality should work. Eventually we may
want to test condition variables and thread creation. (Though in the short term, I only expect
those to be used in main program code, not library code, so we can force that program to
link with the thread library and use condition variables unconditionally, even when the
library's use of mutexes has to test for the support first.)

On AIX, we get: no weak symbol support; stub functions not available in libc; dlopen finds
pthread symbols, even looking at an object not linked with the thread library specifically.

On Tru64, we have: no weak symbols; stub functions not available in libc. Since having
dlopen pull in the thread library is a bit dicey in general, we may not want this to
automatically pull in thread support, but the alternative is to build with no thread support at
all. Or maybe use dlopen(NULL) to look for pthread support in the main program?