Why isn't processing relevant to the environment variable made to MT-safe?

[Takashi Nishiie]

Hi,

The following questions are frequently carried out from the 
customers who are transplanting to Linux the software which 
is running by other OS's.

Why can't the function relevant to the environment variable 
be done in MT-safe? Specification only supposes that it is 
not necessary to be thread-safe. Specification is not 
necessarily forbidden from it being thread-safe.

Reference:
 http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html

Surely, in mounting of the function relevant to the present
environment variable, I also agree with it being a suicidal
act on the processing which changes an environment variable
in a multithread environment. However, isn't this problem a
problem solvable if the function relevant to the environment
variable is improved?

About this problem, there is the following contribution in the past.

(1) Bugzilla:#4350 Reentrancy problem between strftime() and setenv()
http://sourceware.org/bugzilla/show_bug.cgi?id=4350

(2) getenv not thread safe
http://sources.redhat.com/ml/libc-alpha/2004-02/msg00165.html

(3) getenv not thread safe
http://sources.redhat.com/ml/libc-alpha/2005-08/msg00050.html

Since it is not necessary to have these discussions thread-
safe by specification, although it is the conclusion of not 
making it thread-safe, I think that the conclusion will be 
rather narrow-minded. Since surely there is fault about these
corrections that improve getenv(), it will be a fair argument
to have not adopted a draft amendment.
As the another solution method, there is a method of improving
mounting of a function which changes the environment variable
from which getenv() is making the cause of generating SIGSEGV.
By this correction, I think that the code which the software 
which does not change an environment variable in a multithread
environment corrected does not have any influence in order not
to perform.

The following patches are proposed as an actual draft amendment.
glibc-setenv-fj20070808.patch

Since it is not necessary to make it thread-safe by 
specification, to be sure, the idea of not making it thread-
safe is a fair argument.However, can't another viewpoint 
discuss?