Don't setenv in multi-threaded code on glibc

What&#x27;s interesting is that setenv itself is protected by a lock so multiple parallel calls to setenv ought to work (I didn&#x27;t actually check). getenv doesn&#x27;t use a lock.<p><a href="https:&#x2F;&#x2F;sourceware.org&#x2F;git&#x2F;?p=glibc.git;a=blob;f=stdlib&#x2F;setenv.c;h=e2164371ade896e9b3342754724e5ca381beb64e;hb=HEAD#l55" rel="nofollow">https:&#x2F;&#x2F;sourceware.org&#x2F;git&#x2F;?p=glibc.git;a=blob;f=stdlib&#x2F;sete...</a>

(2017)<p>Discussed back then:<p><a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13528407">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=13528407</a> (104 comments)

Is there <i>ever</i> a reason to call setenv? execve and posix_spawn both let you pass an environment.<p>Edit: hmm I guess variables like LD_PRELOAD and PATH that get used by the standard lib you might want to set. Or if any other libraries modify their runtime behavior based on env vars.