This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
- From: Stan Shebs <stanshebs at google dot com>
- To: Andi Kleen <andi at firstfloor dot org>, Roland McGrath <roland at hack dot frob dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, munroesj at linux dot vnet dot ibm dot com, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Steve Munroe <sjmunroe at us dot ibm dot com>, Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>, stli at linux dot vnet dot ibm dot com, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Date: Fri, 18 Sep 2015 11:44:27 -0500
- Subject: Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
- Authentication-results: sourceware.org; auth=none
- References: <55F33220 dot 8050105 at linux dot vnet dot ibm dot com> <20150917043712 dot GA6834 at vapier dot lan> <55FACCF4 dot 1050200 at linux dot vnet dot ibm dot com> <20150917175102 dot 39DD32C3B22 at topped-with-meat dot com> <1442513371 dot 10636 dot 2 dot camel at oc7878010663> <20150917181945 dot E92852C3B40 at topped-with-meat dot com> <1442514665 dot 2348 dot 38 dot camel at reserved-bit dot com> <20150917194823 dot D23452C3B40 at topped-with-meat dot com> <87twqskcsb dot fsf at tassilo dot jf dot intel dot com> <20150918063251 dot GA2213 at vapier dot lan>
On Fri, Sep 18, 2015 at 1:32 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On 17 Sep 2015 13:32, Andi Kleen wrote:
>> Roland McGrath <roland@hack.frob.com> writes:
>> > The main point is to separate the internal API infrastructure that will be
>> > used pervasively across the source tree and set the terms for how we
>> > describe a tunable (i.e. naming, types, et al) from the "back end"
>> > implementation of any particular scheme for getting values into the
>> > system.
>>
>> I don't see how such a complicated procedure is needed to add simple
>> tunables. It seems just an elaborate way to say "I can't make up my mind"?
>
> glibc is known for its stability and strong guarantees of not breaking
> ABIs. describing something as simple seems to brush that off -- we don't
> want to introduce knobs hastily that we are going to regret and be stuck
> with forever. perhaps this particular discussion has been dragging on a
> bit, but glibc isn't really the place for experimentation (which is then
> released directly to users) and for seeing what sticks purely by throwing
> things against the wall. i'd rather we be overly conservative.
> -mike
Empirically, progress in free software projects has been due more to
throwing and observing stickiness than to cautious approaches, and I
know the specific examples have already come to mind as you're reading
this, so I don't need to recite them yet again. :-)
But part of the point of using a branch-supporting source control
system is exactly to support experiments. Is the concern that if a
tunable branch becomes popular, there will be too much pressure to
merge it wholesale, good and bad parts together?
Stan