[mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov

...

Hey, this sounds awesome. So you seem to be suggesting that Boost.Config should not touch *_THREADS until we sort out the meaning of those?

[snip]

But now that I looked at the code, it doesn't really seem that much easier. There is a comment in win32.hpp: [snip] that indicates that our past discussion (this is not the first time this comes up) has had an effect.

Oh, I couldn't find any threads on this topic before. Maybe I should try again :) As for that comment, that still seems to have not differentiated between being multi-threaded and having a threading-API for Boost.Threads available which I think is the fundamental problem as you suggest below.

Mixing /Za and /Ze still seems to result in inconsistent BOOST_HAS_THREADS, though.

Mixing /Za and /Ze? One can't possibly do that, can they? Or did you mean something else. This breaks

detail/lightweight_mutex, for example. It even seems to break Regex, there are a number of BOOST_HAS_THREADS checks there that use the "are we in MT mode" meaning of the macro, as opposed to its "do we have a threading API" meaning.

How can we test this? What I've currently done is the following: #if defined(BOOST_BUILDING_THREADS) \ && defined(BOOST_DISABLE_WIN32) && defined(_WIN32) \ && !defined(BOOST_DISABLE_THREADS) && !defined(BOOST_HAS_PTHREADS) # define BOOST_DISABLE_THREADS #endif I've run all the tests in <threading>multi and they seem to pass though I haven't gone through the log (depending on exit code). Should I try it in single? In any case, I appreciate your comments. Sohail