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: Update on freeze status of glibc 2.18?


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.


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