-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of John Maddock Sent: Wednesday, June 22, 2005 4:02 AM To: boost@lists.boost.org 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