Re: [boost] Re: Re: Re: Re: Re: Thread Lib and DLL

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-03-27 11:04:10

David Brownell said:
> "William E. Kempf" <wekempf_at_[hidden]> wrote in message
> news:33588.192.168.1.1.1048742312.squirrel_at_frodo.kempf-ville.com...
> Ahhh, the light bulb just went on, I finally understand.  However, it
> does seem like this usage of TLS is a corner case, that is refactoring
> code to be thread safe.  I can see how this could be useful and may be a
> larger corner that I am aware, but it is something that I have not had
> to do before. However, it seems like the solution to this problem has
> some very severe consequences, namely forcing the user to compile with a
> DLL rather than a static lib on Win32 systems.  I understand that you
> would like to make the thread library as easy and error-free to use as
> possible, but that solution that requires the use of a DLL prevents me
> from using a library that I greatly value.

Actually, it's a very significant use case, not a corner case.  In
addition, other use cases can result in the same problems.  When a library
allocates TLS, it does so because it needs to maintain state for a thread
it did not create.  After all, if it created the thread, there are easier
and more efficient methods to maintain state.

> I have two main issues with using a DLL, one is another corner case, and
> the second is far less practical but more of an aesthetic.  The first is
> this: on a recent project, we had a requirement that the final binary
> was one and only one .exe.  Due to the nature of the project, anything
> else would be unacceptable (the discussion of why would lead to another
> conversation :). I could not have used the threads library in its
> current state.  Secondly, when I ship a product, I want the customer,
> programmer or not, to view its internal workings as magic.  I don't want
> them to know how I am doing anything.  Obviously they can hex edit the
> binary and figure out anything they want to, but that takes a more
> skilled person that the one who is able to see a dll and know that I am
> using boost threads.  Admittedly, this is not a sound scientific
> complaint, but still valid in my eyes.

The first is very valid.  I never claimed to like the DLL requirement ;). 
In fact, I've been in search of a solution that didn't require this (and
for more reasons than just wanting to support static linking!) from the
outset.  Unfortunately, I don't believe there is a solution at this point.

The second is totally uncompelling.  If hiding usage is all your after,
rename the DLL (do this by changing the stage rule in the Jamfile).

> I would be more than happy to try and help with a solution that would
> handle both of the corner cases, or at least allow the library user to
> compile as desired while knowing the consequences of their
> recompilation.  I hope that the case is not closed on restoring the
> static library compilation in future versions of the thread library.

It's not closed, but it's in definate limbo until after V2 is complete,
since that will change which cases require TLS cleanup.  But I definately
want a better solution to this problem as well, so don't be discouraged.

> After all of this, maybe the thread docs need this question answered as
> part of the FAQ? :)

Yes, it does, and I'll work on that shortly ;).

-- 
William E. Kempf