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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk