This is the mail archive of the 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: [RFC] Make getenv O(1)

On Fri, Oct 18, 2013 at 04:07:05PM +0200, OndÅej BÃlka wrote:
> On Fri, Oct 18, 2013 at 05:46:57PM +0400, Alexander Monakov wrote:
> > On Fri, 18 Oct 2013, OndÅej BÃlka wrote:
> > > You could argue that this does not help when likely case is that
> > > variable is not defined. For that I would need posix say that changing
> > > variable name via environ pointers is illegal.
> > 
> > Indeed; I would also ask if such functions are allowed to query interesting
> > environment variables once on first call and then cache the result (similar to
> > how the dynamic linker stashes initial LD_LIBRARY_PATH on the side and calls
> > to dlopen do not check the environment again).
> > 
> > Alexander
> This could be done by following macro with global renaming of
> getenv->GETENV.
> Also do we support in libc setenv to change behaviour?
> #define GETENV(x) ({ \
>   static char *__ret; \
>   static int __cached; \
>   if (__builtin_constant_p (x) && !__cached) \
>   { \
>     __ret = getenv (x); \
>     __cached = 1; \
>   } \
>   __builtin_constant_p (x) ? __ret : getenv (x);})

I think this is the best approach, either via such a macro or simply
writing out the caching directly. However the above code performs
unsynchronized access on __cached and __ret. In particular the
compiler could store __cached before storing __ret, or due to cache
line issues, __cached might simply become visible to other cores
before __ret does.

IMO the proper fix is to put the above in a function with proper
synchronization, and make a macro which simply expands to the right
static objects and a call to the function with pointers to those
static objects.


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