Making getenv more multi-threading--robust?

[Stephan Bergmann]

On 09/13/2012 11:06 PM, KOSAKI Motohiro wrote:
>> So I think it's a reasonable change.
>> File a bug in bugzilla about it first.
>
> Or reopen 5069 or 4887?
> They seems to discuss very similar or the same issue.

Thanks for digging these out.  So it looks like I am at least the third 
person to come up with what is effectively the same (somewhat obvious, 
anyway) patch for this (after 
<http://sources.redhat.com/ml/libc-alpha/2004-02/msg00165.html> "getenv 
not thread safe" by Michael Eager in 2004 and 
<http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c0> "env thread 
safety problem" by zhangxiliang in 2007).  Given that previous patches 
have been turned down in no uncertain terms (cf. 
<http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c10>), I wonder if 
it is actually worth it to come up now with effectively the same patch 
again?

If it should be worth it after all, I guess it is probably best to 
reopen 5069 and start with the patch provided there.  After all, it uses 
an rwlock to potentially improve performance for getenv-intensive 
applications (or do you have an even better approach in mind, Torvald?). 
  Also, my understanding is that it already covers the deadlock issue 
discussed there alright, but my understanding may well be wrong there.

[My (potentially naive) personal opinion is that "Modifications of 
environment variables are not allowed in multi-threaded programs." 
(manual/startup.texi) and "Any
program that uses putenv or setenv makes itself not thread safe." 
(<http://sourceware.org/bugzilla/show_bug.cgi?id=5069#c10>):

- For one are unfortunate deviations from SUSv4: 
<www.opengroup.org/onlinepubs/9699919799/> "The Open Group Base 
Specifications Issue 7" merely states that each of getenv, putenv, 
setenv, unsetenv need not be thread-safe (where it defines "thread-safe" 
as "a function that may be safely invoked concurrently by multiple 
threads," but, granted, that should likely be interpreted here as not 
pertaining only to calls of the individual functions, but to any 
combinations of calls to them), and the C Standard requires "The 
implementation shall behave as if no library function calls the getenv 
function."  However, the status quo for glibc is that even a 
multi-threaded program only calling setenv and malloc (which is one of 
those "library functions" covered by the C Standard, and which 
internally calls getenv in glibc) is broken.

- And for another are in contrast with the existing locking in 
stdlib/setenv.c.]

Stephan