"Michael Gopshtein" <mgopshtein@gmail.com> writes:
That's not the case with "native" TLS support (it promises to zero out all values in released slot), but it's good to know that this is undefined for thread_specific_ptr.
BTW, is it because such pattern of use is not considered interesting? For example, in our application there are "Database" objects which are created and destroyed dynamically, and each Database has a unique connection per thread, which are stored in the TLS. The connections are also stored in seperate lists, and are released when the Database is no longer in use - so the "default" behavior of the native API (both Win32 and pthreads) is OK with us.
Allowing this is a potential for memory leaks. pthread_key_delete does not run the destructor function, so if you have dynamically allocated memory (or other resource) referenced by the key value you have a leak. By its very nature, thread_specific_ptr has dynamically allocated memory for each key value, so it is important to ensure that it is correctly deleted in each thread. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976