[config] BOOST_DISABLE_THREADS defined by Boost.Config
Joe Gottman quite correctly points out in http://svn.boost.org/trac/boost/ticket/1762 that shared_ptr should honor user definitions of BOOST_DISABLE_THREADS and disable MT support. Unfortunately, despite documenting quite clearly that BOOST_DISABLE_THREADS is a user macro, Boost.Config defines it in some situations. This means that I can't rely on this macro to reflect the user's intent, as I don't know whether it's been set explicitly by the user, or implicitly (and incorrectly IMO) by Boost.Config.
Peter Dimov wrote:
Joe Gottman quite correctly points out in
http://svn.boost.org/trac/boost/ticket/1762
that shared_ptr should honor user definitions of BOOST_DISABLE_THREADS and disable MT support.
Unfortunately, despite documenting quite clearly that BOOST_DISABLE_THREADS is a user macro, Boost.Config defines it in some situations. This means that I can't rely on this macro to reflect the user's intent, as I don't know whether it's been set explicitly by the user, or implicitly (and incorrectly IMO) by Boost.Config.
My gut feeling is to remove the code in suffix.hpp that defines it when BOOST_DISABLE_WIN32 is set (which is the only place Boost.Config sets it I believe) and see if anyone complains. John.
Peter Dimov wrote:
Joe Gottman quite correctly points out in
http://svn.boost.org/trac/boost/ticket/1762
that shared_ptr should honor user definitions of BOOST_DISABLE_THREADS and disable MT support.
Unfortunately, despite documenting quite clearly that BOOST_DISABLE_THREADS is a user macro, Boost.Config defines it in some situations. This means that I can't rely on this macro to reflect the user's intent, as I don't know whether it's been set explicitly by the user, or implicitly (and incorrectly IMO) by Boost.Config.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The code in suffix.hpp looks like #if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) \ && !defined(BOOST_DISABLE_THREADS) && !defined(BOOST_HAS_PTHREADS) # define BOOST_DISABLE_THREADS #endif As far as I can tell, the purpose of this is to disable threading if Windows is disabled and there is no other threading system available. I think we can get the same result in a much clearer fashion without touching BOOST_DISABLE_THREADS by the following: #if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) # undef BOOST_HAS_WINTHREADS #endif Joe Gottman
Joe Gottman wrote:
Peter Dimov wrote:
Joe Gottman quite correctly points out in
http://svn.boost.org/trac/boost/ticket/1762
that shared_ptr should honor user definitions of BOOST_DISABLE_THREADS and disable MT support.
Unfortunately, despite documenting quite clearly that BOOST_DISABLE_THREADS is a user macro, Boost.Config defines it in some situations. This means that I can't rely on this macro to reflect the user's intent, as I don't know whether it's been set explicitly by the user, or implicitly (and incorrectly IMO) by Boost.Config.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The code in suffix.hpp looks like
#if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) \ && !defined(BOOST_DISABLE_THREADS) && !defined(BOOST_HAS_PTHREADS) # define BOOST_DISABLE_THREADS #endif
As far as I can tell, the purpose of this is to disable threading if Windows is disabled and there is no other threading system available. I think we can get the same result in a much clearer fashion without touching BOOST_DISABLE_THREADS by the following:
#if defined(BOOST_DISABLE_WIN32) && defined(_WIN32) # undef BOOST_HAS_WINTHREADS #endif
Doug, what effect would none of BOOST_HAS_WINTHREADS, BOOST_HAS_PTHREADS and BOOST_HAS_THREADS being defined have on shared_ptr? John.
John Maddock wrote:
Doug, what effect would none of BOOST_HAS_WINTHREADS, BOOST_HAS_PTHREADS and BOOST_HAS_THREADS being defined have on shared_ptr?
Well. BOOST_HAS_THREADS is an overloaded macro. It can mean one of two things: 1. Whether the compiler/runtime is in multithreaded mode. In this case, the absence of BOOST_HAS_THREADS would indicate that the compiler/runtime only supports a single thread, and hence, a library may use that to safely disable synchronization. 2. Whether a threading API is available. In this case BOOST_HAS_WINTHREADS and BOOST_HAS_PTHREADS provide additional information about which API is available. The problem is that BOOST_HAS_THREADS isn't very useful in practice, no matter what meaning is chosen. Its absence cannot be used to assume a single thread (because it gets turned off when there's no threading API), and it cannot be used to assume lack of threading API (because of BOOST_DISABLE_WIN32.) So shared_ptr ignores it as much as it can. To get back to your question, BOOST_HAS_WINTHREADS is not used by shared_ptr, so it doesn't matter whether it's defined or not.
Peter Dimov wrote:
John Maddock wrote:
Doug, what effect would none of BOOST_HAS_WINTHREADS, BOOST_HAS_PTHREADS and BOOST_HAS_THREADS being defined have on shared_ptr?
Well.
BOOST_HAS_THREADS is an overloaded macro. It can mean one of two things:
1. Whether the compiler/runtime is in multithreaded mode. In this case, the absence of BOOST_HAS_THREADS would indicate that the compiler/runtime only supports a single thread, and hence, a library may use that to safely disable synchronization.
2. Whether a threading API is available. In this case BOOST_HAS_WINTHREADS and BOOST_HAS_PTHREADS provide additional information about which API is available.
The problem is that BOOST_HAS_THREADS isn't very useful in practice, no matter what meaning is chosen. Its absence cannot be used to assume a single thread (because it gets turned off when there's no threading API), and it cannot be used to assume lack of threading API (because of BOOST_DISABLE_WIN32.)
So shared_ptr ignores it as much as it can.
:-( So the question becomes, how do you want these macros to behave? John.
To get back to your question, BOOST_HAS_WINTHREADS is not used by shared_ptr, so it doesn't matter whether it's defined or not.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
John Maddock:
So the question becomes, how do you want these macros to behave?
The specific issue that I have is the user macro BOOST_DISABLE_THREADS being set by Boost.Config. I want to be sure that user macros are only set by the user and reflect his intent. In general, it would be nice if BOOST_HAS_THREADS actually means: "Defined if the compiler, in its current translation mode, supports multiple threads of execution." as described in the documentation. The current behavior of "strict mode" disabling BOOST_HAS_THREADS does not match the documentation. BOOST_HAS_WINTHREADS is documented to mean: "The platform supports MS Windows style threads." but its approximate meaning today is: "#include <windows.h> works" I don't dispute that it might be useful to know whether <windows.h> can be included or not, of course.
Peter Dimov wrote:
John Maddock wrote:
Doug, what effect would none of BOOST_HAS_WINTHREADS, BOOST_HAS_PTHREADS and BOOST_HAS_THREADS being defined have on shared_ptr?
To get back to your question, BOOST_HAS_WINTHREADS is not used by shared_ptr, so it doesn't matter whether it's defined or not.
Why doesn't shared_ptr use BOOST_HAS_WINTHREADS, as opposed to the various WIN32 macros? Joe Gottman
participants (3)
-
Joe Gottman -
John Maddock -
Peter Dimov