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

[Ben Craig via cfe-commits]

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