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

[Siddhesh Poyarekar <siddhesh at redhat dot com>]

On Wed, 10 Oct 2012 16:20:19 -0700 (PDT), Roland wrote:
> I really hope there will be a way to use this from C, e.g.
> 
> __thread type x;
> static void __attribute__((thread_destructor (x))) foo (type *x_ptr)
> { ... }
> 
> I'm pretty disinclined to add features to libc whose only possible use
> is via C++.

I don't see why this shouldn't be possible.  Based on my reading of the
thread_local specification, it is __thread + a few features like:

* Ability to declare them within blocks - they're analogous to static
* Ability to have non-trivial constructors and destructors.

Neither of them are impossible to add in the future as extensions.
They duplicate the functionality of pthread_key to a certain extent
though.

> Who says preventing DSO unloading is the right semantics?  The obvious
> analog to global destructors is to run them all on dlclose.  That's
> difficult to do if the semantics are that the destructor runs on the
> thread owning the variable.  (They'd be running inside a signal
> handler or something scary like that.)  It's not so hard if the
> destructor takes the specific object pointer as a parameter and might

The destructor does take an object pointer.  I could keep a static
process-wide list of destructors instead of the current thread-local
one and use locking to do this.  It won't work if the destructor
depends on some context within its current thread.  The only such
context I can think of right now is other thread_local or __thread
variables.  Or pthread_key_t for that matter.

C++11x does not seem to say anything about thread_local behaviour when
DSOs are involved.  Maybe we could read that as the default behaviour
being the rule, i.e. destroy all variables defined by a DSO when it is
unloaded as you said.

> run on any thread.  What is supposed to happen when you dlopen an
> object defining thread_local variables with constructors when there
> are already multiple threads?

It depends on which threads use the thread_local variable.  If it is
used, it will be constructed and if it is constructed, then libstdc++
will register a destructor for it through us.


Siddhesh