Re: [boost] Boost.config not recognize threading support enabled?
-----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
[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.
Sure? _GLIBCPP_HAVE_GTHR_DEFAULT tells you whether the compiler and std lib were compiled with threading support or not, as long as the change is limited to linux on arm, just how many such tests would we need?
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.
Or you could just spell your new macro BOOST_HAS_THREADS :-) No changes needed then. John.
participants (2)
-
BRIDGES Dick -
John Maddock