On Fri, Nov 18, 2011 at 2:04 AM, Peter Dimov
Phillip Hellewell wrote:
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?
Very. By specification, TLS cleanup occurs in the same thread that allocated the data (because the data may have been allocated by a thread-specific allocator). When thread_specific_ptr is destroyed, it obviously can't do that.
I can understand an argument against doing it if it is too hard, but why is it so bad to change the spec to allow for an option as long as it is clearly documented that it should not be used if you are using a thread-specific allocator? Put another way, why do we care more about protecting those who might use a thread-specific allocator than protecting those who might use thread_specific_ptr as a member var? Ok, here's another idea: How about a new class, object_specific_thread_specific_ptr! :) Then we don't have to alter thread_specific_ptr. If nothing else, can we at least ask Anthony to add a Note to the documentation warning against using thread_specific_ptr as a non-static member var?
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.
Either map< weak_ptr<Object>, buffer > or set< weak_ptr<Object> > with map< thread_id, buffer > in the object, as I see it.
Hmm, say I never thought about using a weak_ptr to help me. Let me think about that for a bit...
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.
I'm not sure about that. Let's take the first option. What's the problem with it? No locks are needed, and in the function that creates a new map entry for the current object you can purge the expired weak_ptr entries in order to not let the map grow out of hand.
Ok, I think I understand how this could work. There's only one tiny problem though. Although most of my code always creates an Object inside a shared_ptr, it is allowed and there are some places that just create one on the stack and use it, e.g., within a function. Correct me if I am wrong, but this idea can't work unless I forcibly disable the ability to create an Object except via an Object::create() that returns a shared_ptr. Thanks, Phillip