Displaying 3 results from an estimated 3 matches for "3baf62d1".
2013 May 23
0
[LLVMdev] Usage of getenv() inside LLVM and thread safety
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
2013 May 23
2
[LLVMdev] Usage of getenv() inside LLVM and thread safety
...#39;t think
introducing locking around this is the "right" solution. Can we just make
this value an argument to the constructor?
-- Sean Silva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130523/3baf62d1/attachment.html>
2013 May 23
4
[LLVMdev] Usage of getenv() inside LLVM and thread safety
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