
Dear boosters, As far as I've heard a while back, the only reason [thread] library cannot be built as a static library was because of TSS. That to me (and to others as I've seen) seems quite a show-stopper - in a lot of apps I don't use the [thread] lib just because of this. Most of my multi-threaded applications (around 95%) and as I know a lot of other multi-threaded apps. don't need TSS. Even if they do, usually they don't need advanced clean-up code (reason for why [thread] was required to be a DLL). ***Most*** of the time, any allocated TSS objects can be let to leak resources (which they hardly have - mostly IMHO some small amount of allocated memory). The above make me think that we really should enable [thread] to be a static library again ;). It should be documented in the docs that the static version of the [thread] runtime will leak TSS objects, and users can choose whether they will use [thread] as a DLL or as a runtime static lib. What do others think? As a side-note, allowing the [thread] lib to be a static lib is quite simple (please you gurus out there, correct me if I'm wrong). In fact, here's the patch. (note: config.hpp = boost/thread/detail/config.hpp, and I did not modify the jamfile.V2, since I can't test it) Best, John // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP #define BOOST_THREAD_CONFIG_WEK01032003_HPP #include <boost/config.hpp> // insist on threading support being available: #include <boost/config/requires_threads.hpp> #if defined(BOOST_HAS_WINTHREADS) # if defined(BOOST_THREAD_BUILD_DLL) # define BOOST_THREAD_DECL __declspec(dllexport) # elif defined(BOOST_DYN_LINK) // john.torjo # define BOOST_THREAD_DECL __declspec(dllimport) # else # define BOOST_THREAD_DECL // linking to library # endif #else # define BOOST_THREAD_DECL #endif // BOOST_HAS_WINTHREADS // john.torjo /* // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_thread // // If we're importing code from a dll, then tell auto_link.hpp about it: // # define BOOST_DYN_LINK // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled */ #endif // BOOST_THREAD_CONFIG_WEK1032003_HPP # Copyright (C) 2001-2003 # William E. Kempf # # Permission to use, copy, modify, distribute and sell this software # and its documentation for any purpose is hereby granted without fee, # provided that the above copyright notice appear in all copies and # that both that copyright notice and this permission notice appear # in supporting documentation. William E. Kempf makes no representations # about the suitability of this software for any purpose. # It is provided "as is" without express or implied warranty. # # Boost.Threads build Jamfile # # Additional configuration variables used: # 1. PTW32 may be used on Win32 platforms to specify that the pthreads-win32 # library should be used instead of "native" threads. This feature is # mostly used for testing and it's generally recommended you use the # native threading libraries instead. PTW32 should be set to be a list # of two strings, the first specifying the installation path of the # pthreads-win32 library and the second specifying which library # variant to link against (see the pthreads-win32 documentation). # Example: jam -sPTW32="c:\pthreads-win32 pthreadVCE.lib" # Declare the location of this subproject relative to the root. subproject libs/thread/build ; # Include threads.jam for Boost.Threads global build information. # This greatly simplifies the Jam code needed to configure the build # for the various Win32 build types. import ./threads ; { template thread_libs ## sources ## : <template>thread_base ## requirements ## : <sysinclude>$(BOOST_ROOT) ## default build ## : ; # Base names of the source files for libboost_thread. CPP_SOURCES = condition mutex recursive_mutex thread tss xtime once exceptions barrier threadmon ; lib boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <runtime-link>static # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; dll boost_thread : <template>thread_libs ../src/$(CPP_SOURCES).cpp : <define>BOOST_THREAD_BUILD_DLL=1 <runtime-link>dynamic # the common names rule ensures that the library will # be named according to the rules used by the install # and auto-link features: common-variant-tag ; stage bin-stage : <dll>boost_thread <lib>boost_thread #: <tag><debug>"d" : debug release ; install thread lib : <dll>boost_thread <lib>boost_thread ; }

"John Torjo" <john.lists@torjo.com> wrote in message news:40839E26.5020403@torjo.com...
I'm pretty sure this is correct.
All true enough, perhaps, but in the version of Boost.Thread in the thread_dev branch (which, as I've mentioned before, I'm slowly merging into the main branch as I have time), the thread class itself uses tss rather extensively, which complicates the issue quite a bit. the
I agree about the desirability of it (I am, in fact, using it that way myself in some projects). Primarily for the reason I mentioned above, I'm not sure about the practicality of it in the long run. I don't know if you remember seeing it, but what do you think about the approach Roland posted some time back that allowed a static library to act as if it were a dll?
[snipped long patch] Mike

that is a shame. And I'm not sure exactly why does thread rely on it so much? Would it be a big issue if the TSS cleanup didn't happen? By the way, could I have (read) access to the version of [thread] you're working on?
Glad we're on the same side ;)
myself in some projects). Primarily for the reason I mentioned above, I'm not sure about the practicality of it in the long run.
Having [thread] as a DLL complicates life a lot. As said before, I've ***abandoned*** (not used) [thread] for quite a while, just because of this issue. However, now I have some time to catch up on working on the [smart_assert] library, which depends on [thread]. I really want to be able to release [smart_assert] as a static library. Making it a dynamic library will probably turn off many possible users of it - it would be just one more DLL to worry about. Therefore, I made this patch.
I'm all for it! As long as we can have [thread] as a static library, I really don't care how that happens. Until the TSS issue is solved, would you please commit this patch to the CVS? I think it's a good workaround - for the current [thread] version in the CVS. I'd really hate to abandon [thread] once again - just because of this issue. Best, John

"John Torjo" <john.lists@torjo.com> wrote in message news:4083F1FE.6020409@torjo.com...
merging
The reasons are two-fold: 1) The thread class becomes a handle class that holds a reference-counted pointer to a thread_data class. When a thread class is created, it gets access to the thread_data class for the thread using TLS. 2) As you might guess from the name of the thread_data class, there is other information associated with each thread; for instance, a thread id, a flag indicated whether the thread has been cancelled (yes, there is an exception-based implementation of thread cancellation), etc.
Would it be a big issue if the TSS cleanup didn't happen?
Given the above-mentioned changes, it probably is. The TSS cleanup is what calls the thread_data destructor, which is what performs the thread cleanup (CloseHandle for Win32, pthread_detach for pthreads).
Everything is on the thread_dev branch of the Boost cvs. Most of the work was done by Bill Kempf, but he didn't completely finish it; I'm primarily reviewing the code, changing or adding what seems necessary to me to make it complete, then merging it into the main branch after asking for comments on this list. I haven't done anything with the thread class yet, but it makes sense to me why the changes were made, including the dependence on tss. For access, either do a cvs update of Boost's ...\libs\thread and ...\boost\thread directories using anonymous access and the the "-r thread_dev" switch or see http://cvs.sourceforge.net/viewcvs.py/boost/boost/libs/thread/src/thread.cpp... and http://cvs.sourceforge.net/viewcvs.py/boost/boost/boost/thread/thread.hpp?on.... I'm glad to have as many interested eyes as possible see the changes. [snip]
I'm looking forward to it! the
I'd really hate to abandon [thread] once again - just because of
I'll take a look at it as soon as I can; unfortunately, probably not today. If you don't hear back from me soon about it, please remind me! this issue.
Best, John
Thanks, Mike

(note: config.hpp = boost/thread/detail/config.hpp, and I did not modify the jamfile.V2, since I can't test it)
oops. the config.hpp was wrong. Hopefully, not anymore :D Best, John // Copyright (C) 2001-2003 // William E. Kempf // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, // provided that the above copyright notice appear in all copies and // that both that copyright notice and this permission notice appear // in supporting documentation. William E. Kempf makes no representations // about the suitability of this software for any purpose. // It is provided "as is" without express or implied warranty. #ifndef BOOST_THREAD_CONFIG_WEK01032003_HPP #define BOOST_THREAD_CONFIG_WEK01032003_HPP #include <boost/config.hpp> // insist on threading support being available: #include <boost/config/requires_threads.hpp> #if defined(BOOST_HAS_WINTHREADS) # if defined(BOOST_THREAD_BUILD_DLL) # define BOOST_THREAD_DECL __declspec(dllexport) # elif defined(BOOST_DYN_LINK) // john.torjo # define BOOST_THREAD_DECL __declspec(dllimport) # else # define BOOST_THREAD_DECL // linking to static library # endif #else # define BOOST_THREAD_DECL #endif // BOOST_HAS_WINTHREADS // john.torjo // // Automatically link to the correct build variant where possible. // #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_THREAD_NO_LIB) && !defined(BOOST_THREAD_BUILD_DLL) // // Set the name of our library, this will get undef'ed by auto_link.hpp // once it's done with it: // #define BOOST_LIB_NAME boost_thread // // And include the header that does the work: // #include <boost/config/auto_link.hpp> #endif // auto-linking disabled #endif // BOOST_THREAD_CONFIG_WEK1032003_HPP
participants (3)
-
Alexander Terekhov
-
John Torjo
-
Michael Glassford