Boost logo

Boost :

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-26 10:45:44


William E. Kempf wrote:
> David Brownell said:
>> I am curious as to why the new version of the Thread library does not
>> provide a static library in the 1.30 version of boost. After reading
>> some initial posts, I have seen references to thread local storage,
>> but haven't seen anything that documents why this makes a static
>> library impossible. All thing considered, I find a static library is
>> much more desirable than a dll.
>
> It has been discussed numerous times on this list, as well as on the
> Users list. TLS cleanup can only be done on the Win32 platform with
> code in the thread itself (which won't work for threads created
> outside of Boost.Threads) or with code in DllMain.

A possibility. Simulate the DllMain DLL_PROCESS_DETACH through a member
function call in the thread class which should only be used for those who
are using a static library version of the library. The member function must
be called before the thread function exits in the static library version.
For the DLL version, the member function must be ignored or you can simply
not have the member function call in the DLL version. The onus would be on
those using the static library version to always make this call before their
thread function exits, but would at least provide them wioth the possibility
of using a static library version. Of course there may be other
ramifications which cause this idea not to work, or even getting it to work
properly would be too much trouble, but I thought I would suggest it anyway.

It may not be worth thinking about possible solutions of building a static
library version of Boost.Threads. I know that for myself I always creates
DLLs when distributing applications but as a 3rd party developer I always
leave open the possibility that there are people who like to distribute the
applications as a single EXE which uses static libraries and the static
library version of their compiler's RTL.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk