Re: [PATCH] Add GLIBC_PTHREAD_ELISION_ENABLE tunable

[Roland McGrath <roland at hack dot frob dot com>]

> I may have misunderstood what you meant; my understanding of your
> objection was that you did not want an envvar for each tunable and
> wanted a single envvar or config file, which seems to be different from
> what you've mentioned now, which seems to be to not provide any way to
> externally specify tunables and only have the internal scaffolding in
> place.  I believe Carlos may have misunderstood as well since we
> discussed this in depth later and seemed to be talking the same thing.
> 
> If what I understand now is correct, the first cut should be easier. 
>  I'll try to get a proper patch up for review after a week or so.

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

After the BoF was over, you, Carlos, and I then went on to start to
minimally discuss back end issues despite the stated plan to differ that
discussion.  In that context, I briefly reiterated my general concern about
all environment variables (which I will continue to argue when we actually
get to that).  The notion of a single environment variable was an example
of a way to mitigate some of those concerns if I were to capitulate on the
firm stance about environment variables.  It was not a proposal, except to
suggest that you might use it as a straw-man starting proposal when we
began that discussion after landing the internal API.  (We also discussed
much more forward-looking ideas like a shared memory block manipulated by
an external utility.  All of that was in the realm of ideas we might
consider in the future, once we have established the context of the
internal API for tunables.)

I stand by my core positions.  We have not recently discussed my positions
about back end issues.  I don't really want to get into any of that in
earnest until we have reached consensus on the internal API and it is close
to being landed.  Once that's done, then people can go off and implement
working prototypes of particular ideas (be they environment variables or
whatever else) and we can play with those as part of reaching consensus on
what we actually want to have in the code.  (Multiple such implementations
with configure switches to choose among them might be something we choose
to do.)