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

[Justin Holewinski]

That sounds like a missed multi-threading issue with LLVM.  I can't imagine
why the user should be forced to serialize creation of MCContext objects. I
would suggest filing a bug for this.  A simple lock probably wouldn't be
too detrimental to performance here, since MCContext objects shouldn't be
created too often.


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
>



-- 

Thanks,

Justin Holewinski
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/191f4698/attachment.html>