While considering various ways to get rid of the remaining intentional memory leak of the tss implementation, I came upon the following question: How long may a thread access it's tss storage anyway? I did not find anything in the documentation about the topic. Looking into the destructor of thread_specific_ptr reveals ~thread_specific_ptr() { reset(); } which in turn implies, that the thread(s) which are using it should have already terminated, when the main thread has exited (called its dtor list). Now when one has control over the lifetime of the threads this poses no problem, since they simply need to be terminated before main() ends. The situation is completely different when writing a piece of code (a library) that has to use tss and shall work with foreign threads too. The library writer in this case has no control over the lifetime of the threads (native or not). So I am wondering if it is possible to refine the inner workings of the thread_specific_ptr without changing the interface to account for these cases? Perhaps only a static pointer should be embedded that points to dynamic memory that will not be touched by destructor calls, but controlled in lifetime be real thread-detachements. (The last one frees everything which is really global.) How is the situation for other libraries, say e.g. pthreads? Are they allowed to run after main ended? Or is this simply considered bad programm behaviour? Any comments? Roland