Making getenv more multi-threading--robust?

[Roland McGrath]

> If different threads frequently call getenv, this could decrease
> performance due to cache misses and/or contention on the lock.

Indeed.  As getenv is a dumb linear search, anything calling it in a
performance-critical situation is stupid to begin with.  But we should
avoid degrading any such existing cases, however stupid they are.

> *If* this is problem that we face in practice, then we can likely
> synchronize differently in getenv (i.e., return consistent information
> without any special ordering guarantees wrt setenv calls).  In that
> case, I can help with that.

Such help is most welcome.


Thanks,
Roland