bcraig added a comment. > Hmm, maybe? If other global destructors run after ~DtorListHolder(), and > they cause a thread_local to be initialized for the first time, > __cxa_thread_atexit() might be called again. I was thinking that dtors would > get re-initialized in that case but it appears it does not. So yeah, I think > I'll need to leak the pthread_key_t.
> > I'm not sure how to avoid leaking the actual thread_local objects that get > created in that situation. There's nothing left to trigger run_dtors() a > second time. I'm not concerned about the loss of memory or pthread_key resources in this leak, as it is a very short-lived leak (the process is going away after all). We do need to have an idea of what happens with the destructor invocations for the other kinds of resources though. I think the C++14 spec says what should happen. > 3.6.3 Termination > > 1. [...] The completions of the destructors for all initialized objects with > thread storage duration within that thread are sequenced before the > initiation of the destructors of any object with static storage duration. If > the completion of the constructor or dynamic initialization of an object with > thread storage duration is sequenced before that of another, the completion > of the destructor of the second is sequenced before the initiation of the > destructor of the first. If the completion of the constructor or dynamic > initialization of an object with static storage duration is sequenced before > that of another, the completion of the destructor of the second is sequenced > before the initiation of the destructor of the first. What that means for this implementation is that I think that __cxa_thread_atexit is allowed to be called during run_dtors. If running the dtor for a thread local variable 'cat', we encounter a previously unseen thread_local 'dog', the compiler will call the ctor, then register the dtor with __cxa_thread_atexit. Since it is the most recently constructed thread local object, I would expect the 'dog' dtor to be the next dtor to be run. You may be able to support this just by moving "elem = elem->next" below the dtor invocation. http://reviews.llvm.org/D21803 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
