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] |
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?
Attachment:
glibc-setenv-fj20070808.patch
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |