Re: [PATCH 1/9] Add vectorized getenv for glibc use

[Andi Kleen <andi at firstfloor dot org>]

On Mon, May 13, 2013 at 11:23:17AM +0530, Siddhesh Poyarekar wrote:
> On Sat, May 11, 2013 at 12:32:40AM +0200, Andi Kleen wrote:
> > On Thu, May 09, 2013 at 03:03:13PM +0530, Siddhesh Poyarekar wrote:
> > > > +    _dl_glibc_var;
> > > > +    __glibc_var_init;
> > > 
> > > These should be sorted.
> > 
> > FWIW the existing entries are not sorted.  I moved my new ones.
> 
> Then they ought to be sorted and pushed as an obvious change before
> your patch.

If it obviously works unsorted I don't think that's a requirement.

> 
> > > We might want to enforce namespaces from the beginning here.  How
> > > about GLIBC_PTHREAD_MUTEX_TYPE or similar?  I don't want to bikeshed
> > > on the actual name; I'm fine as long as a good namespace convention is
> > > established.
> > 
> > The environment variables are called GLIBC_MUTEX and GLIBC_RWLOCK
> > I don't think it makes sense to call the internal names anything
> > else.
> 
> Sorry, I guess I wasn't clear enough.  I meant namespaces for the
> environment variables since they are good candidates for inclusion
> into generic tunables.

The original concern was that PTHREAD_* would collide with some other
project (I always considered that far fetched, but ok)

So PTHREAD_MUTEX is now called GLIBC_MUTEX and PTHREAD_RWLOCK
GLIBC_RWLOCK

Now your new concern is that there is something else _inside_ glibc
that also calls itself mutex, but is not a libpthread mutex, would
collide? And the same for rwlock?

That is not far fetched, that is absurd.

-Andi
-- 
ak@linux.intel.com -- Speaking for myself only.