This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix quick_exit to match C++11 specification.


On 06/08/2016 03:41 PM, Florian Weimer wrote:
>> In which case it's only 3 years of usage.
> 
> Or non-usage. I don't think there are many users. In Fedora rawhide,
> the only reference is in some auto-generated wrapper code in the
> smokeqt package.

This doesn't count the user applications built on top of Fedora
or other downstream rpm-based distributions though.

The real complication is that we can't know how many users of a public
API, and thus once we release the API we generally support it forever.

There are some cases where we have recently deprecated very very old
headers, or types, but none of these break backwards compatibility with
existing applications.
 
>>> commit ba384f6ed9275f3966505f2375b56d169e3dc588
>>> Author: Siddhesh Poyarekar <siddhesh@redhat.com>
>>> Date:   Mon Feb 18 19:08:21 2013 +0530
>>>
>>>     C++11 thread_local destructors support
>>>
>>> I don't see how your change makes a different for the libstdc++ approximation.
>>>
>>> What am I missing?
>>
>> Nothing.
>>
>> * Is 3 years enough usage to justify a compat symbol?
> 
> As I tried to explain, it's unclear where to put the compat symbol.

In the case of quick_exit, we need only sufficient state such that
the lower-level exit helpers know now to call thread_local destructors.

In the case of __cxa_thread_atexit_impl, the new version would need to
register destructors in another list which is not normally called by
the code path that quick_exit uses, but is called by the path that
exit uses. Given that the code to call those lower-level exit helpers
is all consolidated in one place to reduce duplication, it would be
more complicated versioning __cxa_thread_atexit_impl.

However, it is zero complication if we don't versioning anything.

>> * Is the cost of the compat symbol and long term maintenance
>>   worth the benefit to our users?
> 
> I doubt it, every additional symbol makes dynamic linking a tiny bit slower.

The problem is that a consequence of our failure is the users
application doesn't work. So we should err on the side of caution.

Even if additional symbols make dynamic linking a tiny bit slower,
that's a distinct problem we need to consider solving other ways.

In summary:
- I am being conservative by versioning quick_exit.
- quick_exit is in my opinion the easiest interface to version
  and logically related to the quick_exit conformance issue with
  C++.
- We do need to look at making dynamic linking faster. We might start
  with: bug 15310, bug 17645.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]