"William E. Kempf" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost