Boost logo

Boost :

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-03-26 11:18:16

Edward Diener said:
> 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.

Workable, if the user makes absolute certain he calls this method from
every thread that accesses TLS. However, he may not know this, for
example when a library function uses Boost.Threads internally and
allocates TLS with out the user knowing. This is just a variation on the
"you must use this thread creation routine if you use our libraries"
solution that MS uses for the C RTL and MFC. I think it's fragile... and
many users fail to understand the issues here and thus do the wrong thing.

> 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.

Yes, and for that reason I certainly dislike the DLL only packaging of
Boost.Threads. But it seems the safest and most viable solution.

William E. Kempf

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