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
> 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
That seems much more reasonable than completely emasculating dlclose.
> (wouldn't work e.g. for OpenMP though, as that keeps some threads around
> to avoid constant pthread_create/pthread_join).
Use of any long-lived TLS data in OpenMP-annotated code seems inherently
ill-defined for exactly that reason. AIUI the OpenMP annotations don't
give you any guarantee about how much parallelism you actually get, so
using __thread or thread_local variables in such code fragments seems like
it ought to be out of spec entirely. Is it well-specified in some way I'm
not thinking of?
Uses of thread_local variables with nontrivial destructors in
OpenMP-annotated code fragments seems like it would be rare at the most.
So the "outstanding destructions counter" scheme would likely make the
unknowable thread lifetimes a nonissue for dlclose behavior in practice.
> What we perhaps for C could do is add some new attribute,
> __attribute__((tls_ctors_dtors)) or whatever, which would result in it being
> treated as C++ thread_local in this regard (and some way how to specify what
> the ctor/dtor for some __thread var is).
Yes, that sounds like exactly the C extension to exercise this
functionality I was asking for. The following seems quite reasonable to
me:
static void x_ctor (void), x_dtor (void);
__thread int x __attribute__ ((thread_ctor (x_ctor), thread_dtor (x_dtor)));
> The thread_local dtors aren't run upon exit in threads other than the one
> calling exit (otherwise thread_local would be effectively unimplementable
> if there is more than one thread still running on exit.
Sure, that makes sense (and is consistent with pthread_key_create destructors).
Thanks,
Roland