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

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

> I don't think we want implicit destructor calls like this from C; in G++ 
> __thread and thread_local behave differently because supporting dynamic 
> initialization and destruction causes run-time overhead for all uses.

Then why do we have __attribute__ ((destructor)) when there is already
atexit?  I'm looking for some consistency with past feature decisions,
which seem to have been in the direction of providing GNU C extensions
fairly closely equivalent to C++ features.

> I think it would make sense to have a user-accessible thread_atexit 
> entry point, however, so that people can explicitly register the 
> destructor when they explicitly initialize the variable.

Certainly my foremost concern is that there be some pure (GNU) C way to
exercise any underlying functionality we might add to the library at the
behest of C++ features.  The idea that it should be an especially close
parallel to the C++ feature is secondary.

> Right, that's the problem.  In general we can't assume that reaching 
> into another thread's local data will work sensibly.

That seems like a reasonable conservatism, as does eschewing things like
having dlclose interrupt threads so they can run destructors in their own
context.

What I've really been doing is trying to force you all to clearly elucidate
the design space, the tradeoffs, and the decisions made.  I take umbrage at
any instance where the C++ community or G++ maintainers decides on a
feature and its details with implicit demands on the implementation of
libc, dynamic linkers, pthreads, etc., and concludes on what those non-C++
components must do, without airing the issues thoroughly and consulting
with the experts on and implementors of those components.  The thread_local
semantics specified in C++11 appear to be a glaring example.  I certainly
hope there isn't a whole raft of more such issues lurking.

It may well be that the conclusions on what C++11 now implicitly requires
of dynamic linking behavior are entirely correct.  But it's IMHO
inexcusable that a patch to implement this deep in the bowels of glibc
after the C++ standard and the G++ implementation have already been baked
is the first we are hearing about the subject.


Thanks,
Roland