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

From: David Brownell (david_brownell_at_[hidden])
Date: 2003-03-27 10:44:02

"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:33588.192.168.1.1.1048742312.squirrel_at_frodo.kempf-ville.com...
>
> David Brownell said:
> >> // In library Foo
> >>
> >> void some_library_foo()
> >> {
> >>    boost::thread_specific_ptr<Foo> p;
> >>    // other stuff
> >> }
> >>
> >> // In Application Bar which uses library Foo with out any knowledge //
> >> that Foo used Boost.Threads
> >> void bar()
> >> {
> >>    some_library_foo();
> >> }
> >>
> >> int main()
> >> {
> >>    __beginthread(&bar, ....); // leak, but how could the developer
> >> know?
> >> }
> >>
> >
> > I'm not sure I understand this example completely.  Is this the case
> > where library Foo's author has created the some_library_foo function
> > with the intention that it will be accessed by a thread, but leave the
> > actual thread creation up to the user of the foo library (the bar
> > application in your example)?
> >
> > If this is correct, it seems like Foo should either a) not burden Bar
> > with the knowledge that threads are being used and handle thread
> > creation itself or b) allocate locally to some_library_foo without using
> > thread_specific_ptr.
>
> Foo doesn't create any threads, but Bar does.  So (a) isn't the answer.
> I'm not sure what you mean by "allocate locally to some_library_foo",
> since that's precisely what's being done.  Telling Foo not to use
> thread_specific_ptr is the same as telling them not to use Boost.Threads,
> which doesn't sound like the answer to me!
>
> To make this more concrete, TLS is most often used to make legacy
> interfaces, such as the classic example of strtok, which maintain state
> across calls, thread safe.  That's what's being done in the hypothetical
> "some_library_foo".  TLS is really the only solution here (other than
> changing the legacy interface, which often isn't an option), which is why
> I said telling them not to use thread_specific_ptr is the same as telling
> them not to use Boost.Threads.
>
> --
> William E. Kempf
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>

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.

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.

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.

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

Thank you for your patience and explanations,
David Brownell