This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Destructor support for C++11 thread_local variables
On Thu, 11 Oct 2012 08:55:56 +0200, Jakub wrote:
> async signal context is wrong too. All you could do to allow
> unloading would be to track how many TLS dtors for each library are
> outstanding in each thread, and allow dlclose when no thread contains
> outstanding TLS dtors for the library (with the possible exception of
> current thread, those can be destructed just fine). That would allow
> dlclose for uses where all thread_local accesses with ctors/dtors are
> done in threads that are pthread_joined before dlclose (wouldn't work
It sounds like we only care about destructors called before DSO unload
and not after, i.e. we only want to make sure that the destructors are
*not* called if the DSO it was defined in is already unloaded.
If that is the case, then I think I could manage this with a
process-wide list of destructors (instead of the current thread-local
one) implemented with locking and keeping a reference of the
link_map and our TID in tls_dtor_list. On object unload, we iterate
through the list to simply remove those destructors for other threads
without executing them. The only downside possibly is that destruction
will be slower due to the larger list and lock contention.
Siddhesh