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: Making getenv more multi-threading--robust?


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


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