Re: [boost] Boost.config not recognize threading support enabled?

From: BRIDGES Dick (Dick.Bridges_at_[hidden])
Date: 2005-06-22 16:10:56

> -----Original Message-----
> From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On
> Behalf Of John Maddock
> Sent: Wednesday, June 22, 2005 4:02 AM
> To: boost_at_[hidden]
> Subject: Re: [boost] Boost.config not recognize threading support
enabled?
> 
> > - BOOST_HAS_PTHREADS is defined in posix_features.hpp after
<unistd.h>
> > is included.  I had hoped this was a good thing.  ;)
> 
> Yes.
<snip> 
> Yes: for some compilers (including gcc on some platforms), just
because the
> platform has pthreads, and advertises it's presence in unistd.h, this
does
> *not* mean that the C++ compiler can generate thread aware/safe code
unless
> special measures are taken (a special command line option usually, for
> example -mthreads on cygwin), or not at all in some cases (gcc on SGI
Irix
> for example).  C++ compiles have to take special care when generating
> exception handling and / or RTTI code that may involve hidden globals,
in
> order for them to be thread safe.  This is not the case for C
compiles, and
> remember that unistd.h is a C header!
> 
<snip> 
> Failing everything else, I think the way to handle this is with
something
> like this in libstdcpp3.hpp:
> 
> #if defined(macro-that-identifies-linux-on-arm) &&
> defined(_GLIBCPP_HAVE_GTHR_DEFAULT)
> #define BOOST_HAS_THREADS
> #endif

[Dick] My primary reservation about this approach is based upon my
assumption that the "macro-that-identifies-linux-on-arm" would be an
attribute of the compiler.  I still can't get used to the idea that
multi-threaded or single-threaded is compiled into the gcc
cross-compiler itself, while little-endian and big-endian are command
line switches. %>[  The multiplicity of targets and threading models
might require a number of such tests that would be difficult to manage.

> Any closer?

[Dick] I'm of two minds about the following suggestion:  it's either a
kludge or introduces a certain pleasing symmetry. ;)

Since BOOST_DISABLE_THREADS is used to unconditionally disable threads,
the user-wielded imperative BOOST_ENABLE_THREADS (tested at the same
place in suffix.hpp) would [almost] unconditionally define
BOOST_HAS_THREADS - subject only to the existing verification that the
threading API has been identified and is recognized.

For compilers that do not provide detectable compile-time indications
that threading is enabled, this seems to me to be a fairly
straight-forward and minimally invasive adaptation.  Although this puts
the onus on the user, it does have the advantage of being independent of
the target and potentially stable.

> John.
> 

[Dick] Regards,
Dick