This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/9] Add vectorized getenv for glibc use
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Andi Kleen <andi at firstfloor dot org>, libc-alpha at sourceware dot org, Andi Kleen <ak at linux dot intel dot com>
- Date: Tue, 14 May 2013 03:03:11 -0400
- Subject: Re: [PATCH 1/9] Add vectorized getenv for glibc use
- References: <1367537252-30831-1-git-send-email-andi at firstfloor dot org> <1367537252-30831-2-git-send-email-andi at firstfloor dot org> <20130503001819 dot GP20323 at brightrain dot aerifal dot cx>
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?
Cheers,
Carlos.