Re: [PATCH] Destructor support for C++11 thread_local variables

[Roland McGrath <roland at hack dot frob dot com>]

> 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