Re: [boost] Re: Thread Lib and DLL

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