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
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org, Jakub Jelinek <jakub at redhat dot com>, JasonMerrill <jason at redhat dot com>
- Date: Thu, 11 Oct 2012 12:08:33 +0530
- Subject: Re: [PATCH] Destructor support for C++11 thread_local variables
- References: <20121010210546.7322c6fa@spoyarek><20121010232019.15DE22C053@topped-with-meat.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