Re: [boost] BOOST_HAS_PTHREADS, BOOST_HAS_SCHED_YIELD tests in config_test not strict enough

From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-11 11:02:20

John Maddock:

> OK, I've taken a shot at fixing this, but I don't have Solaris to test on,
> so <shrug> !

Neither do I. :-)

> Basically <unistd.h> always advertises the presence of pthreads on Solaris
> so BOOST_HAS_PTHREADS gets set regardless.  I've now added an additional
> check to solaris.hpp to turn it off for gcc when _PTHREADS is not set.

Yep. But won't this code in suffix.hpp:

#if (defined(__MT__) || defined(_MT) || defined(_REENTRANT) \
    || defined(_PTHREADS)) && !defined(BOOST_HAS_THREADS)
#  define BOOST_HAS_THREADS
#endif

turn it back on?

I admit that the task of setting BOOST_HAS_THREADS is pretty hard. But the 
current practice of distributing the setting into compiler/platform/suffix 
headers seems too fragile to me. I'm not sure I understand all the subtle 
details yet though.

> Yeh, g++ has always been lax about advertising whether it's in thread safe
> mode or not.

Right.

My point however was that this is no longer true, starting from g++ 4.1. 
_REENTRANT is now being set properly (and ignored by Boost.Config).

(Unfortunately intel-linux still emulates the older g++ practice of always 
setting _REENTRANT.)

> Lets see where these changes get us, and then we need to decide what to do
> on Win32 in strict mode when <windows.h> is unavailable :-)

I believe that the fact that <windows.h> is unavailable (this can happen in 
non-strict mode as well under VC++ Express, if the Platform SDK hasn't been 
installed) should be indicated by a new macro that is documented as such.

There's also the general problem of using BOOST_DISABLE_THREADS inside 
Boost.Config to communicate lack of threading support from one header to 
another. I don't necessarily view this as unacceptable... as long as 
Boost.Config is unquestionably right to do so; that is, as long as there is 
no situation in which the user would want to not define it.

Still, the easiest way out is just to use an internal macro for 
communication and leave BOOST_DISABLE_* as pure user macros.