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.
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.
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.