Re: Calling __cxa_thread_atexit_impl directly, from C code

[Florian Weimer <fweimer@redhat.com>]

* Adhemerval Zanella Netto:

> On 30/08/22 04:37, Florian Weimer wrote:
>> * Adhemerval Zanella Netto:
>> 
>>> It would mean that libgcc_s would need to build and use the fallback
>>> implementation in the case of failure, which is suboptimal (although not
>>> sure it would be an improvement over abort on failure).
>> 
>> The fallback implementation also has to allocate memory.
>> 
>> The alternative would be to throw std::bad_alloc.
>
> Yeah, but the suboptimal is not solely for the allocation memory part,
> but also for the missing synchronization and ordering.  But I also think
> moving the failing handling to caller it still better than the hard hammer
> or aborting the process (even though I agree it won't improve that much).

But I think this argues indirectly for making a __cxa_thread_atexit_impl
variant callable from C code: C++ code with -fno-exceptions might want
to use this as well, and there is really no good way to handle such
fallible C++ constructs (here: implicit destructor registration) without
exceptions.

>>> But I also think for compat reasons we can't really change 
>>> __cxa_thread_atexit_impl, since C++ constructors will be the ones responsible
>>> to call __cxa_thread_atexit and afaik it assumes it can not fail (meaning
>>> that any failure will be ignored).
>> 
>> Yes, there is the general problem that for registering an object for
>> destruction, as a matter of principle, you need to try to allocate the
>> data structure in the registry first, and if that is successful, create
>> the object.  Otherwise you may end up with an object and no way to
>> register its destructor.  Perhaps you should just call the destructor at
>> this point and throw std::bad_alloc.
>> 
>> I guess we should go with the static destructor counting approach
>> instead. 8-/
>
> Why strategy more specially do you mean the counting approach?

If we know how many TLS variables with d'tors there can be, we can
allocate the memory upfront during thread creation.

> I just reread the 'Counting static __cxa_atexit calls' thread and tend
> to agree with you that having the number of required unique
> __cxa_atexit calls seems slight better than a failable .init_array
> mode.

Please say so on the thread as well. 8-)

Thanks,
Florian