Re: Thread-local support for non-POD data objects

[Rich Felker <dalias at aerifal dot cx>]

On Fri, Jul 12, 2013 at 10:51:28PM +0530, Siddhesh Poyarekar wrote:
> hi,
> 
> There's an item on the glibc TODO master that mentions glibc support
> for non-POD objects.  I believe the glibc support required here is
> limited to providing support for registering destructors and executing
> them on thread exit.  This is true for C++11 thread_local as well as
> openmp thread local objects.  This feature has been provided in glibc
> for 2.18, so I believe we could remove this item from the list.  Does
> anybody have any objections to that?
> 
> There's still the question of providing a C extension that implements
> a similar requirement, but that only needs compiler support now
> afaict.

I have a couple questions about the thread-local dtor support. The
current implementation of __cxa_thread_atexit_impl does not check the
return value of calloc, and crashes if calloc failed. The
__cxa_thread_atexit_impl function, however, does have a return value.
I was not able to find the code in libstdc++ that calls it (maybe it's
not there yet), but does this calling code check the return value, and
would it instead be possible for __cxa_thread_atexit_impl to return
failure and for the caller to throw an exception in this case? And
would this behavior even be conforming?

My feeling is that it should be impossible for code like this to crash
or generate an exception:

  thread_local int foo = gettid(); // stupid example

but this is impossible unless storage for the TLS dtor information is
reserved prior.

Maybe it's too late to redesign all this, but I think the C++ compiler
should generate extra TLS space for non-POD TLS, sufficient to contain
a structure like:

  struct nonpod_tls_desc {
    void *objl
    void (*dtor)(void *);
    struct nonpod_tls_desc *next;
  };

then __cxa_thread_atexit would merely need to link these descriptors,
and would not have to allocate anything. And code like the above would
have zero risk of failure.

If it is too late to change things, in musl I'm probably going to have
to implement something like the above without the help of the
compiler, by having the dynamic linker automatically allocate extra
TLS like the above whenever it detects a C++ DSO with non-POD TLS
objects. Part of the reason I'm raising these issues are as part of
figuring out whart musl will need to do to handle C++ non-POD TLS.

Rich