Re: Calling __cxa_thread_atexit_impl directly, from C code

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 26/08/22 05:31, Florian Weimer via Libc-alpha wrote:
> Do we support calling __cxa_thread_atexit_impl directly?  The function
> is not documented, nor is it declared in any installed header.
> 
> I think the answer is yes, because we support different C++
> implementations, and they have to call __cxa_thread_atexit_impl for
> thread-local destructors, either directly or through a wrapper
> (__cxa_thread_atexit for libstdc++, as proposed for the Itanium C++
> ABI).

Not only that, but if the C library does not provide the C++ replacement
will most likely have serious drawbacks such as no handling of dso_symbol 
(so no synchronization between thread_local destructors and
dclose) and no ordering enforcing in main thread thread_local destructors.
The libc++ implementation does document the possible issues with the
fallback.

> 
> There's interest in this because it's much easier to use than
> pthread_key_create if you have to avoid linking against libpthread and
> you target glibc releases between 2.18 and 2.33 (although it is possible
> to use weak symbols, as in the libstdc++ implementation in
> libstdc++-v3/libsupc++/atexit_thread.cc).

Although it seems to be used solely by C++ and the interface is generic enough
so any runtime/language might use it as well for any thread exit deallocation
cleanup, I am not sure it would be feasible to export or support calling it
from C code.

It does make sense to use __cxa_thread_atexit for C++ since it aims to have
interoperability with C, but it is not clear to me how useful it would be for
a language or runtime that does not aim for it (it would be simple to just
do all the required work on the thread wrapper or similar facility).

The interface also have two annoying peculiarities where calling from C code
is not straightforward: 

  1. Any memory failure aborts the process, which is far from ideal to a
     generic interface.

  2. User need to correctly declare __dso_handle; using NULL (or any invalid
     value) will bound the to callback to main program (which is not correct
     if use within a shared library).

So I think it would be better to provide a different interface.