David Brownell said:
> Thank you very much for taking the time to answer those questions, I
> didn't know the situation was that compilcated! I guess I am still not
> sure what prevents the following from working:
>
> //User code
> void ThreadProc(void)
> {
> ...
> }
>
> boost::thread *pThread = new boost::thread(ThreadProc);
>
> //And within the thread code
> void InternalThreadProc(const boost::function<void> &func)
> {
> func();
> //TLS cleanup
> }
>
> thread(const boost::function<void> &userFunc)
> {
> ...
> InternalThreadProc(userFunc);
> }
>
> Again, the code is rough, but I hope I am communicating clearly.
// 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?
}
If you know what routines use Boost.Threads internally, and if you
remember to access those routines only in Boost created threads (or call
the cleanup routine explicitly in other threads), then you'll have no
problem. But this is complex, and very error prone, and gets worse with
every new thread creation routine with these same cleanup issues. And how
confident are you that you'll know what third party vendors have used?
I've personally located bugs caused by a third party library using MFC
with out documenting it, and so we used only the RTL creation routines.
It's already bad enough with 3 different routines provided by MS. There's
already issues with Boost.Threads because of this (for instance, if you
use Boost.Threads to create a thread that accesses MFC routines that use
TLS, you'll leak, because I elected to use _beginthread instead of
AfxBeginThread).
--
William E. Kempf
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
