[PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable
Andi Kleen
andi@firstfloor.org
Thu Sep 17 20:46:00 GMT 2015
Roland McGrath <roland@hack.frob.com> writes:
Roland,
>
> 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"?
> What we agreed on was that we could relatively easily reach consensus on
> this internal API. We explicitly deferred specific discussion on what I'm
> calling "back end" issues until after the API is in place.
Please make a decision. This whole train wreck is going on for far too
long now. And tunables are badly needed.
An "internal API" doesn't help any user. If some plugin scheme is done
the first usable version of it will be just the defacto implementation.
I thought we had a consensus earlier when I was told to implement
environment variables with opt-in config file. Is that now already
forgotten?
> I stand by my core positions.
Nobody can figure out what your core positions are, they don't
actually describe any way to solve the problem.
-Andi
More information about the Libc-alpha
mailing list