[boost] Re: two thread libs? [was: Re: Re: logging library]

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-30 09:08:00

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