[cxx-abi-dev] thread_local destructors

[Jason Merrill]

On 09/22/2012 12:42 AM, Dennis Handly wrote:
>> From: Jason Merrill <jason at redhat.com>
>>> do we need a __cxa_finalize_thread function?
>
>> I've been experimenting with registering a
>> private finalize function as a pthread_key_create destructor;
>
> I guess its name is __cxa_finalize_thread.  :-)

In my prototype it's a static member function of a class in the unnamed 
namespace.  :)

>> except that they don't get run for the main thread
>> unless it explicitly calls pthread_exit.
>
> And how to handle that?

Well, one way would be to add to the normal atexit list a call to a 
finalize function that operates on the list for whatever the current 
thread is.  But to be conformant we would have to arrange for this 
finalize function to always be the first thing on the list.

For a longer-term solution I think we're leaning toward supporting this 
stuff in glibc directly.

>> 3.6.3:
>> Destructors for initialized objects with thread storage duration within
>> a given thread are called as a result of returning from the initial
>> function of that thread and as a result of that thread calling
>> std::exit.
>
> Nothing about pthread_exit or pthread_cancel.
> For the former, you get it.  For the latter, is that like _exit where you
> don't want to run them.

I think it makes sense to run them for pthread_cancel as well, since 
pthread_cancel runs pthread_cleanup_* cleanups.

> Also, for the case of std::exit, would that have to sit on top of exit and
> do more work?

As above, it probably makes sense to integrate this with exit/__cxa_atexit.

>> 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.
>
> This would mean std::exit would have to kill all of the threads first?

No, exit only runs the destructors for the thread it's called from.  Any 
other active threads don't run their destructors.

>> Another possibility would be to lock affected shlibs in memory, such as
>> with the glibc RTLD_NODELETE flag to dlopen.
>
> Ok.  This is a user requirement?  Or we somehow "add" RTLD_NODELETE to
> the loaded shlib?

I was thinking to add it somehow when we call the thread atexit.

Jason