On Fri, Oct 05, 2012 at 10:29:54AM +0200, Richard Guenther wrote:
> I wonder if an implementation is conforming that performs non-local TLS
> variable inits at thread creation time instead (probably also would require
> glibc support)?
I think it is conforming, but not really doable, because of dlopen.
If you have multiple threads running already and dlopen a library that has
thread_local with ctors, you can construct them in the current thread, but
can't construct them in other threads (even just sending some magic syscall,
interrupting those threads, isn't going to work, because then you'd be in
async-signal context where the number of things you can portably do is
limited, while the constructors can expect to be able to execute arbitrary
code). This is similar to the reason why we want to make libraries
which have thread_local with dtors non-dlcloseable. We can destruct in the
current thread at dlclose time, but can't destruct in other threads (and the
C++ standard isn't aware of dlclose, therefore it can't easily say anything
allowing the dtors not to be run in that case). thread_local dtors for
other threads (from what Jason said, haven't checked the standard) don't
need to run for other threads at exit time (which is a situation very
similar to dlclose).
> Should we document our choice of implementation somewhere in the
> manual? And thus implicitely provide the hint that using non-local TLS
> variables with dynamic initialization comes with an abstraction penalty
> that we might not be easily able to remove?
Unfortunately, that penalty is not only for thread_local vars with
ctors/dtors. There is some penalty even for using
extern thread_local int i;
int foo (void)
{
return i;
}
(as compared to extern __thread int i;), because we have to at least check
whether the weak TLS initializer for i is NULL or not. Other TU could have
thread_local int i = dynamic_initialization ();
Jakub
