On Wed, Nov 16, 2011 at 11:51 PM, Vicente J. Botet Escriba
Yes, this is a know bug (feature for Anthony), that prevents from using them as member objects.
Glad to know I'm not the only one who sees this "feature" as a bug :) I wonder how hard it would be to at least provide an option to clean up all the TLS data when it is destroyed?
Boost.Thread provides a non member function at_thread_exit()
Is this what you were looking for?
Thanks, yeah I think that is what I was looking for. Unfortunately, without the ability to also unhook a callback from the thread exit, it still might not do what I need though :(
My advice is use the static thread_specific_ptr ;-)
I actually do use a static thread_specific_ptr in various places in my code, but this is one scenario where I can't because it must be object-specific too. The buffer is associated with the object. Different objects must not use the same buffer, even if they are operated on by the same thread. That would result in getting the wrong data. The only way I could use a static/global thread_specific_ptr is if it pointed to a map of object (its address) to its buffer. But that puts me back in the same boat as I started in, with the same same problems as trying to use a thread_specific_ptr as a member var. Phillip