Boost logo

Boost :

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.


John Torjo
-- john_at_[hidden]
-- - viewing/filtering logs is just too easy!

Boost list run by bdawes at, gregod at, cpdaniel at, john at