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

[Justin Holewinski]

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.
var?


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
>



-- 

Thanks,

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