[LLVMdev] Usage of getenv() inside LLVM and thread safety

[Reid Kleckner]

Right.  glibc's amusing stance is that you setenv/putenv are not thread
safe, but getenv is.  I assume Ruby exposes setenv and therefore simply not
calling setenv isn't an option.

Would it solve your problems if all getenv() calls happened at
cl::ParseCommandLineOptions() time?


On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote:

> Hello,
>
> In Rubinius we're seeing an occasional crash inside LLVM that always
> happens inside getenv(), which is used for example when creating a
> MCContext (inside lib/MC/MCContext.cpp, it checks
> getenv("AS_SECURE_LOG_FILE")).
>
> The problem is that getenv() and friends aren't thread safe and Rubinius
> provides a multithreaded system. We can relatively easily get locking setup
> around the getenv() calls we do in Rubinius, but that's really complex to
> be able to do for LLVM. I also don't know what the guarantees are here that
> LLVM wants to provide regarding thread safety of code that happens to have
> a getenv() call inside it.
>
> What would be the best approach to solving this? Would it be necessary to
> put locking around this inside our usage of LLVM? Should LLVM provide a
> locking mechanism for this or should there be a way to make the getenv()
> calls optional in the places there are used (like here in MCContext).
>
> Regarding the thread safety, this is what the open group says about
> getenv():
>
> "The getenv() function need not be reentrant. A function that is not
> required to be reentrant is not required to be thread-safe."
>
> http://pubs.opengroup.org/onlinepubs/009696799/functions/getenv.html
>
> --
> Regards,
>
> Dirkjan Bussink
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/a154954e/attachment.html>