John Torjo wrote:
[snip] Static-link build option added
The option to link Boost.Threads as a static library has been added back with some limitations. This feature was originally removed because boost::thread_specific_ptr required that Boost.Threads be dynamically linked in order for its cleanup functionality to work on Win32 platforms. Several options are currently being explored to resolve this issue. In the meantime, the ability to link Boost.Threads statically has been added back with boost::thread_specific_ptr support removed from the statically linked version. The decision to add it back was made because its lack is one of the most frequent complaints about Boost.Threads and because the other approaches that are being investigated to deal with boost::thread_specific_ptr cleanup look fairly promising.
so if I get the latest boost.thread I'll have all this (ability to use it as a static lib)?
Yes, but without tss on Win32.
Note Boost.Threads is still dynamically linked by default. In order to force it to be statically linked, it is necessary to #define BOOST_THREAD_USE_LIB before any of the Boost.Threads header files are #included.
I'm not sure this is ok with me. I think it should still be statically linked by default (see below).
It would, perhaps, except that the static lib doesn't include tss on Win32. I hope it will in the release following the upcoming release, at which point the BOOST_THREAD_USE_LIB would disappear.
Note If the boost::thread_specific_ptr cleanup issue cannot be resolved by some other means, it is highly likely that the option to statically link Boost.Threads will be removed again in a future version of Boost, at least for Win32 platforms. This is because the boost::thread_specific_ptr functionality will be increasingly used by Boost.Threads itself, so that proper cleanup will become essential in future versions of Boost.Threads.
Again, I don't understand why you need thread_specific_ptr within boost.threads so much.
To quote from a past posting: "The reasons [for using tss in the thread class's implementation] 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 [TSS]. 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 indicating whether the thread has been canceled (yes, there is an exception-based implementation of thread cancellation), etc." In other words, the thread class needs to associate thread-specific data with each thread, and the obvious way to do this is to use thread_specific_ptr.
Anyway, if you need thread_specific_ptr so much, maybe we could do away with two libraries, something like: 'thread' and 'thread_ext' or so.
In the thread, we should keep what was roughly before: - mutexes (don't tell me they need TLS) and scoped locks - thread class (no cleanup support) - xtime
In the thread_ext, include whatever needs thread_specific_ptr, and extra goodies - this will have the statically/dynamically linked issue.
I think this would be quite good in the long run, since there are so many libs/applications that only need basic thread support, and who really don't want an extra DLL added to the maintenance list.
As I mention above, I'm hoping to make the dll unnecessary (at least unnecessary for tss cleanup). Splitting everything into two libraries is probably a good approach if I don't succeed, however. Mike