[LLVMdev] Usage of getenv() inside LLVM and thread safety
rnk at google.com
Thu May 23 07:15:11 PDT 2013
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
On Thu, May 23, 2013 at 9:49 AM, Dirkjan Bussink <d.bussink at gmail.com>wrote:
> 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
> 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
> "The getenv() function need not be reentrant. A function that is not
> required to be reentrant is not required to be thread-safe."
> Dirkjan Bussink
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev