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

From: John Torjo (john.lists_at_[hidden])
Date: 2004-06-30 03:08:55

 > [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!