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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-06-30 00:49:40

> [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)?
> 
> 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).
> 
> 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.

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.

Best,
John

-- 
John Torjo
Freelancer
-- john_at_[hidden]
-- http://www.torjo.com/logview/ - viewing/filtering logs is just too easy!