[cxx-abi-dev] thread_local summary

[Jason Merrill]

On 10/02/2012 01:00 AM, Dennis Handly wrote:
>> From: Jason Merrill <jason at redhat.com>
>> I'm currently mangling the init and wrapper functions as normal
>> functions with a function name of _TH <object name> or _TW <object
>> name>, respectively.  I've thought about dropping the function type from
>> the mangling, but don't have a strong opinion.
>
> So is this going to be added to the mangling specs?

Yes, that's the idea.

>> The destructors for the current thread are also run on std::exit.
>
> And we don't care about other threads?

This is what the standard mandates.  Running destructors for other 
threads would require some sort of complicated synchronization 
mechanism; better just to require the user to deal with unwinding the 
other threads appropriately before or during exit.

>> Dennis suggested that we still include the DSO handle in the parameters
>> to this function.  Since there's really no way to run destructors in all
>> threads on dlclose, I don't really see the need; instead, an
>> implementation can use internal mechanisms to improve semantics and/or
>> diagnostics for dlclosing a shared object with pending thread_local
>> destructors.
>
> I don't see any easy way to diagnose it without the DSO handle.
> For static variables, you can look at the address ranges for text and data
> for each shlib that you unload and make a guess on that.  But thread local
> data is in the heap somewhere, with no idea who owns it.
>
> I.e. I don't think you want the C++ runtime to get in bed with the threads
> lib at that low level.  For something that can be easily solved by passing
> that extra handle.

OK, I'm convinced.

Jason