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: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable


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.

> 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". 

-Andi


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