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

From: John Maddock (john_at_[hidden])
Date: 2008-04-11 12:21:10

Peter Dimov wrote:
> 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?

No, well actually yes, but since there is no available threading API, 
(BOOST_HAS_PTHREADS not set), it'll get turned off again...

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

The trouble is - there ain't no easy way - strictly IMO of course!

I accept it's often hard to work out what's setting what macro where - but 
the alternative is a big bunch of spaggetti code to handle all the 
platforms/compilers in one go, which isn't necessarily better.. or worse :-(

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

Is it?  Threading support on Linux should only be turned on when _REENTRANT 
is set, there might be issues on other platforms though... I'll have to look 
into that.

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

Well we have BOOST_DISABLE_WIN32 which is set when <windows.h> is 
unavailable - or alternatively optionally by the user.

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

If we stop setting BOOST_DISABLE_THREADS when BOOST_DISABLE_WIN32 is set 
this issue become moot doesn't it?

John.