From: Andrey Semashev (andysem_at_[hidden])
Date: 2008-03-03 14:00:36
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,
>>> is therefore not transferable. If you could assign one instance to another,
>>> would that affect other threads that had values associated with the old
>>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk