From: Peter Dimov (pdimov_at_[hidden])
Date: 2008-04-11 11:02:20
> 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
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.
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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk