From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-30 09:08:00
John Torjo wrote:
>> 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.
>> 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
> 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.
>> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk