[boost] Re: Re: Thread Lib and DLL

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-03-26 13:30:06

William E. Kempf wrote:
> 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.

The user can just call the method for every thread which uses Boost.Threads
in a static library implementation. If a library ( LIB ) function uses
Boost.Threads internally, then it is up to the library function implementor
to document this and iteratively define a function which can be called which
calls the Boost.Threads function before the thread ends or, if the library
function itself controls the ending of the thread, it must do it itself.

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

I don't doubt its general fragility as far as the end-user goes but if it
enables an end-user to use Boost.Threads in a static LIB version, it may be
still justifiable for them. It is easy enough to explain to the end-user
that because Boost.Threads can not track when the thread ends in a static
LIB, as it can automatically do in a DLL, the end-user must do the "manual"
tracking by notifying Boost.Threads about the thread ending via the
function. There is hardly an end-user involved with Windows DLLs who does
not know about the attaching and unattaching of processes and threads which
runs through DllMain. It would be completely understandable to offer the
more difficult to use static LIB version with an explanation of why this
notification must be done manually for the static LIB as opposed to the DLL.

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

Well, it is up to you. As I say, I generally never use static LIB versions
in my own application software. However, if I distribute 3rd party
components I feel bound to be able to distribute versions as both a DLL and
a static LIB whenever it is functionally possible to do so. So if I were a
3rd party developer who was using Boost.Threads for my own implementation of
something, I might not want to do so because the proposed static LIB version
of my own software could not use a static LIB version of Boost.Threads.
Although I could theoretically use the DLL version of Boost.Threads in the
static LIB version of my own software, I have always been heavily opposed to
mixing static LIB and DLL versions of anything with their implications of
possibly mixing static LIB and DLL RTL and the ensuing hell that usually
causes. So I don't think it is just people who distribute applications who
might find it hard that their is no static LIB version of Boost.Threads but
also other 3rd party developers.