Hi, I haven't followed this thread completely, but I have a question. I'm working on Win 2k, and I'm using VC++ 7.1. Building boost with this toolset, do I need to specify something to make it thread-safe?
TIA, Viv ----- Original Message ----- From: "John Maddock" <[EMAIL PROTECTED]> To: "Boost mailing list" <[EMAIL PROTECTED]> Sent: Sunday, August 31, 2003 12:33 PM Subject: Re: [boost] Re: 1.30.0->1.30.2: no more thread support for Linux? > > > Threading support is on when BOOST_HAS_THREADS is defined, and off when > it's > > > not, or forced off by defining BOOST_DISABLE_THREADS, you'll find both > of > > > these mentioned in the configure generated user.hpp (and in the config > > > docs). > > > > So if I my program runs only on systems that I know support threads, > > and I want shared_ptr to use threading support, my program can guarantee > > this by defining BOOST_HAS_THREADS? No matter whether the user's Boost > > install is - > > > > 1) Simply extracted from the tarball > > 2) Configured without thread support > > 3) Configured with thread support > > > > And I don't need to define anything about the platform thread library > being > > used, like BOOST_HAS_PTHREADS? > > OK lets start with Linux and gcc as a specific and special case - in this > case I think that will work - BOOST_HAS_PTHREADS will be defined anyway, but > remember that your std lib will not be thread safe unless you define > _REENTRANT, and if you do that then BOOST_HAS_THREADS will get defined > anyway by the config system (either the out-the-box version or the > configure'd one). Of course the user could always manually configure boost > in some obscure way, or deliberately disable thread support with > BOOST_DISABLE_THREADS, but if they've done that then you should probably be > emitting a #error not trying to work around it. > > In the general case though, we're back to the situation that your code will > not be thread safe unless you invoke your chosen compiler with some magic > special flag (or in the case of IBM Visual Age use a different compiler > front end altogether), and if you do that then Boost.config will detect it's > presence by whatever macros it sets (usually but not always _REENTRANT) and > turn on BOOST_HAS_THREADS. You should always regard BOOST_HAS_THREADS as > *information*, not as something you set yourself, in 99% of cases if you > find it's not set, then it's because the compiler in it's current mode isn't > capable of producing thread safe code. > > Note for example that Boost.config explicitly defines BOOST_DISABLE_THREADS > for gcc on some platforms because we know that gcc isn't capable of > producing thread safe code on those platforms yet (even though they do have > a perfectly good pthread lib). > > Finally if you're configuring your program via autoconf then there are some > nice looking autoconf macros on the net, for example: > http://ac-archive.sourceforge.net/Installed_Packages/acx_pthread.html. > > Sorry to make this complicated, but threads _are_ complicated.... > > John. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost