[PATCH] D21803: [libcxxabi] Provide a fallback __cxa_thread_atexit() implementation

Ben Craig via cfe-commits cfe-commits at lists.llvm.org
Wed Jun 29 13:06:34 PDT 2016


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





More information about the cfe-commits mailing list