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

Justin Holewinski justin.holewinski at gmail.com
Thu May 23 12:10:33 PDT 2013

This would require threading the value through some LLVMTargetMachine
functions, at the least.  Do we still lock and check the env. var. if the
given value is NULL?  Or just do away with the default coming from the env.

On Thu, May 23, 2013 at 2:30 PM, Sean Silva <silvas at purdue.edu> wrote:

> On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski <
> justin.holewinski at gmail.com> wrote:
>> 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.
>> The deeper question is why we are even checking a "global" here in the
> first place? It goes against LLVM's library-based design. So I don't think
> introducing locking around this is the "right" solution. Can we just make
> this value an argument to the constructor?
> -- Sean Silva



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

More information about the llvm-dev mailing list