Anthony Williams wrote:
Andrey Semashev <andysem <at> mail.ru> writes:
Hi, I have a couple of questions about thread_specific_ptr in 1.35.
1. I can see that there is an ability to set up a logic of reclaiming resources that thread_specific_ptr points to. Why is it limited (a) only to a pointer to function and (b) can only be set up in thread_specific_ptr's constructor? It might be better to provide interface similar to shared_ptr in this way?
a) The interface is how it was in boost 1.34 and prior. The underlying code would allow something more general, but I haven't updated the interface for that yet.
So I guess, I may hope this more general interface will be implemented? In 1.36, maybe? Thanks in advance. :)
b) If it wasn't set up in the constructor, it would have to be set up with every call to reset. There's arguments either way. This is the boost 1.34 (and prior) way.
Yes, and I see nothing bad with it. Shared_ptr does precisely the same, and since this cleanup function is intended to do the same as shared_ptr's deleter does, I don't see why would the interface have to differ. The only tricky thing here is that different threads could assign different cleanup functions to the same pointer. But that isn't very hard to implement, is it?
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.
If you can't change an object after construction, why do you need to copy it? You could just pass around a pointer or reference instead.
I'm not sure I got you right here. My case is quite simple. I have a class that needs to store some data in TLS to avoid thread contention. And I want to keep the class copyable. Now I have to have a member "shared_ptr< thread_specific_ptr< MyData > >" to achieve that, and that's quite clumsy, not to mention the overhead of such solution.