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

From: William E. Kempf (wekempf_at_[hidden])
Date: 2003-03-27 00:18:32

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