getenv not thread safe

[Phil Harman]

Hi,

I'm the guy responsible for ...

http://blogs.sun.com/roller/page/pgdh/20050614


Thanks for your interest. I found this thread through comments left on 
the above blog entry. For completeness, I think it is worth quoting them 
and my response here ...

Posted by *83.28.66.114* on August 15, 2005 at 05:21 AM PDT:
> http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html 
> ,,The getenv() function need not be reentrant. A function that is not 
> required to be reentrant is not required to be thread-safe.''

Posted by Mark Brown on August 15, 2005 at 09:20 AM PDT:
> Any code that relies upon getenv() being thread-safe is inherently 
> non-portable. As the previous commenter points out, the POSIX and the 
> UNIX standards specifications call out getenv() as not guaranteed to 
> be reentrant. While this feature of your getenv() may have benefits, 
> it's not usable in a portable environment.

Posted by Phil Harman on August 15, 2005 at 01:20 PM PDT:
> Well of course that's all very nice, except that some care about 
> *more* than *just* POSIX.
>
> The "MT-Safe" putback to the Solaris libc was made on 92/05/06 
> (according to the SCCS history). We didn't ship a user-level threads 
> library until 1993, which means Solaris has *always* provided a thread 
> safe getenv().
>
> The Pthreads specification *wasn't even ratified* until 1995 (Solaris 
> 2.5 was shipped with support for Pthreads in November 1995).
>
> When I came to tune getenv(), dropping thread safety simply *wasn't an 
> option*. We could argue until the proverbial cows come home about the 
> relative merits of getenv() thread safety. But that's not the point. 
> We said we were for it. We have always shipped it. We must assume 
> there are people who depend on it.
>
> So, quote whatever standards you will! Our getenv() has always been 
> thread safe, but it is now also *fast*! What's the problem? It's 
> certainly not a problem for Solaris! If people need getenv() to be 
> thread safe, they know where to come; if they don't, I think we've 
> shown that we're here to compete.
>

Now to your comment ...

On Mon, 15 Aug 2005 13:49:53 +0200, Jakub Jelinek wrote:
> On Mon, Aug 15, 2005 at 03:16:56AM -0700, Paul Orang wrote:
> > http://blogs.sun.com/roller/page/pgdh/20050614 points
> > out that glibc getenv is not protected against
> > parallel setenvs. Can it be fixed?
>
> getenv is not required to be thread-safe, see
> http://www.opengroup.org/onlinepubs/009695399/functions/getenv.html
> The string returned by getenv may become invalid after next
> setenv/putenv/unsetenv call, so any program relying on thread-safety
> of these is broken.
>
> 	Jakub

I agree, but it's a rather moot point due to the very nature of the APIs 
in question (e.g. that getenv() returns a pointer to the object added to 
the environment with putenv()). Solaris doesn't address this issue 
because it cannot be addressed as the APIs are defined.

However, this is not the only issue of thread safety for getenv(). 
Consider this case ...

While I'm in getenv() for one name another thread calls putenv() with a 
different name, but one which is not already in the environ array. This 
doesn't sound like such a broken thing to do, does it? However, putenv() 
may find that the current environ array is not big enough to hold the 
new value. What happens to me in getenv() if putenv() allocates a new 
array and releases the old one? Someone might get to reuse the memory 
while I'm still in getenv(). It's a SEGV waiting to happen.

In Solaris we used to protect the environ array with a single lock. The 
problem was it didn't scale (and yes, we had customer demand for this). 
My lockless reworking of getenv() handles the above scenario (and 
others). It is safe, but it is also fast. Given the choice of "fast but 
unsafe" or "fast and safe", which one would you run your business on? 
The application may have been ported from Solaris, but the issue may 
have been overlooked (and even extensive testing is unlikely to expose 
the race).

Cheers,

Phil

 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20050815/bff044b7/attachment.bin>