This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix quick_exit to match C++11 specification.
- From: Adhemerval Zanella <adhemerval dot zanella at linaro dot org>
- To: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc: Johan Karlsson <johan dot karlsson at enea dot com>
- Date: Wed, 8 Jun 2016 17:28:53 -0300
- Subject: Re: [PATCH] Fix quick_exit to match C++11 specification.
- Authentication-results: sourceware.org; auth=none
- References: <5751B292 dot 40109 at redhat dot com> <383b6001-e2ef-635a-4240-aa7fba826de3 at redhat dot com> <57525107 dot 5060500 at redhat dot com> <1c6e298e-ae7c-7e7a-d271-dfb75e874a04 at redhat dot com> <575613DA dot 3070209 at redhat dot com> <99119374-6dc7-42c2-451c-b4be759b7cc2 at redhat dot com> <57567CCE dot 2080207 at redhat dot com> <e0755a7a-f83a-423c-be4c-de7ba8e63c5c at redhat dot com> <57569A37 dot 3030002 at redhat dot com> <5756B7DC dot 4030805 at linaro dot org> <5756C971 dot 7010308 at redhat dot com> <17a6f214-14f6-f2de-c8b4-93691187d3c2 at redhat dot com> <57586FC1 dot 30600 at redhat dot com> <eb573789-52a6-cb0c-598f-a91cfa0cce84 at redhat dot com> <57587E32 dot 6020400 at redhat dot com>
On 08/06/2016 17:21, Carlos O'Donell wrote:
> 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.
>
I personally do not see a compelling reason to provide a compatibility
symbol to standard defined C++11 symbol that explicit states its
interface regarding the offended functionality. I would see a reason
to add compatibility if the functionality was not defined or if the
interface was not really setted in the time the function was added in
GLIBC.
If the C++11 application is relying on thread_local destruction
for quick_exit, it is a non-conforming one that might only runs correctly
on GLIBC. I see this as an application issue, not a GLIBC one.