This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Update on freeze status of glibc 2.18?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: Roland McGrath <roland at hack dot frob dot com>, GNU C Library <libc-alpha at sourceware dot org>, Ryan Arnold <rsa at us dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Mon, 17 Jun 2013 14:55:31 -0400
- Subject: Re: Update on freeze status of glibc 2.18?
- References: <51B65DE4 dot 4010107 at redhat dot com> <20130610231903 dot D9C602C09B at topped-with-meat dot com> <51B66222 dot 1040300 at redhat dot com> <20130614224427 dot 4B2532C077 at topped-with-meat dot com> <51BF3CF8 dot 1010901 at redhat dot com> <1371494971 dot 16968 dot 21574 dot camel at triegel dot csb>
On 06/17/2013 02:49 PM, Torvald Riegel wrote:
> On Mon, 2013-06-17 at 12:44 -0400, Carlos O'Donell wrote:
>> On 06/14/2013 06:44 PM, Roland McGrath wrote:
>>>> I will assume that you would not be opposed to a configure
>>>> switch that turns elision on or off with the default being
>>>> elision off, but no questionable env vars to tune behaviour.
>>>
>>> Probably not, if the code enabled by the configure switch does not
>>> diverge from the API and ABI guarantees we already make and does not
>>> include anything generally ugly that we wouldn't want in the tree at all.
>>
>> Agreed. I guess I just wanted to clarify that the major sticking point
>> right now is the env var usage, and without that then it's a matter of
>> Torvald and I making sure the code does what it says and meets our
>> usual guidelines.
>
> The way I read Roland's comment is that independently of whether things
> are controlled via a configure switch instead of an env var, they should
> not diverge from the API or ABI guarantees (and this includes the POSIX
> guarantees such as the relock case requirements for
> PTHREAD_MUTEX_NORMAL). Roland, is that correct?
That's what I mean by "our usual guidelines."
We must not break the pthread API guarantees unless the user is
specifically requesting a non-portable extension to be enabled.
The later would be done specifically by writing new code to take
advantage of elision.
Cheers,
Carlos.