Peter Dimov wrote:
2) In a sense gcc is either "always thread safe" or "never thread safe" depending on how it and libstdc++ were built. For example on Linux (and most other platforms I believe) -pthread does nothing except pass -lpthread to the linker.
So... assuming (1) really has been fixed in gcc-4.1, what's the right thing to do about (2)?
Good question. :-/
We have four options for the <threading>single case:
1. !HAS_THREADS, !HAS_PTHREADS 2. HAS_THREADS, !HAS_PTHREADS 3. HAS_THREADS, HAS_PTHREADS 4. HAS_THREADS, HAS_PTHREADS, add -lpthread
I really have no idea which of these is best. I can see arguments for each. If .o files compiled with and without -pthread are indeed link compatible, our current choice of (3) seems pretty reasonable.
A quick servey of the GCC manual found these entries for -pthread: -pthread Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags. -pthread Adds support for multithreading with the pthreads library. This option sets flags for both the preprocessor and linker. -pthreads Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. This option does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. -pthread This is a synonym for '-pthreads'. So on all platforms that support this, it changes the linker flags and the preprocessor defines but that's it.
A practical problem I have with (3) is that pthread_mutex_trylock links and crashes. But I'm not sure whether this warrants any changes. Maybe the correct way to deal with it is to mark it up and move on.
Do you have a test case?
If we do choose to stay with (3) as our choice, we probably need to revert the has_pthreads test back to the stubs and move the real has_pthreads (and has_pthread_mutexattr_settype) to separate tests outside of config_test.
Sigh :-( Yep. Still not sure what the right answer is yours, John.