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

[Rich Felker <dalias at aerifal dot cx>]

On Tue, May 14, 2013 at 03:03:11AM -0400, Carlos O'Donell wrote:
> On 05/02/2013 08:18 PM, Rich Felker wrote:
> > On Thu, May 02, 2013 at 04:27:24PM -0700, Andi Kleen wrote:
> >> From: Andi Kleen <ak@linux.intel.com>
> >>
> >> This adds a general "vectorized getenv" for glibc internal use.
> >> The motivation is to allow subsystems to access environment variables
> >> cheaply without having to rescan the environment completely.
> >>
> >> The dynamic linker already walks the environment to look for its
> >> LD_* variables. Extend this code to look for a number of
> >> pre-registered GLIBC_* variables too. This can be done at basically
> >> no additional cost. The only two variables currently pre-registered
> >> are for the lock elision code.
> >>
> >> For static builds which do not use the dynamic linker a similar
> >> environment walking function is called at init time.
> >>
> >> The variable values are saved in a global array that can be directly
> >> accessed by libc and related libraries like libpthread.
> > 
> > Doesn't this change behavior if environment variables are later set at
> > runtime? I don't think such use should be supported anyway, but it
> > seems this is an observable functional change, not just an
> > optimization.
> 
> That depends on your view of the defined semantics for the new GLIBC_*
> environment variables.
> 
> I for one would like to say that they are read at program startup and
> never re-read. It makes the most sense for performance and make for a
> simple and easy to understand runtime behaviour.
> 
> Does that make sense?

Yes, I agree it's probably better behavior. But I thought the patch
was also changing (to use caching) the treatment of several
preexisting glibc config variables, in which case it is changing the
behavior, and if so this should be noted.

Rich