Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable

[Mike Frysinger <vapier at gentoo dot org>]

On 18 Sep 2015 18:06, Andi Kleen wrote:
> On Fri, Sep 18, 2015 at 02:32:51AM -0400, Mike Frysinger 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
> 
> This has been discussed since at least two years now.
> There's nothing hasty about the existing procedure. In fact "glacially
> slow" would be a more appropiate description.

i'm aware this particular discussion has been around for quite some time,
but i don't think the result should be "f-it, let's do it live!".

> > 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.
> 
> Does that argue for never changing anything?
> 
> I don't see how you can even test anything without "releasing it to
> users". 

it argues for a solution we're confident isn't going to screw us over
in the long run and looks like it will scale.
-mike

Attachment: signature.asc
Description: Digital signature