Anthony Williams wrote:
Andrey Semashev <andysem <at> mail.ru> writes:
2. Why thread_specific_ptr isn't copyable? Why can't it share TLS keys (or whatever it uses to find the thread-specific resource) in the dynamically allocated cleanup object? I would expect thread_specific_ptr, being a pointer as its name implies, to be copyable. Fundamentally, the TLS key is the instance of thread_specific_ptr itself, which is therefore not transferable. If you could assign one instance to another, how would that affect other threads that had values associated with the old value stored in that instance? If there are no other pointers that own that TLS key, the cleanup functions for all threads are invoked, and the TLS key is released.
How is this to be managed? Cleanup handlers for the TLS key need to run in the context of each thread, and only run when a thread changes its value with reset(), or when the thread exits. You cannot invoke a cleanup handler for another thread.
Hmm, I missed that. But how does it work now? I mean, how the cleanup handlers are called in the current implementation when the thread_specific_ptr is destroyed? You should call them in context of their threads anyway.
The thread_specific_ptr is a bit clunky altogether. I intend to come up with something better in the future, but it may be moot once compilers start implementing the new thread_local storage duration.
I think, efforts on thread_specific_ptr are not completely worthless. Even after C++0x is out and supported by the most wide-spread compilers we will still have to write backwards-compatible code to support older compilers for some time. MSVC 6 support is an example of such evolution history.