Boost logo

Boost :

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

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