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 1/9] Add vectorized getenv for glibc use


On Mon, May 13, 2013 at 03:46:52PM +0200, Andi Kleen wrote:
> 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.

There is a discussion thread in the list archive that you can search
for, where it was decided that the Versions lists ought to be sorted
as a good practice.  The conclusion of that discussion was the last
point in the following wiki document under the Trivial Bug-Fix
Changes:

http://sourceware.org/glibc/wiki/Consensus

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

I did not imply that these names would collide with anything.  If you
read my comment again you'll see that I said that I'm going to try to
incorporate these into a generic tunables support framework I'm
writing for glibc.  One of the points I'm trying to make sure in the
design is that tunable names follow an explicit naming convention that
describes which module they belong to.  It is with that intention that
I requested you to rename those variables.

The result would be that in addition to being able to set
GLIBC_PTHREAD_MUTEX environment variable, one could also set tunables
at a user level or system level using configuration files, something
like this:

pthread.mutex = adaptive
pthread.mutex.retry_lock_busy = 10

and so on.

Siddhesh


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