<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On May 23, 2013, at 11:30 AM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski <span dir="ltr"><<a href="mailto:justin.holewinski@gmail.com" target="_blank">justin.holewinski@gmail.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div>
<div class="gmail_extra"><div class="h5"><br></div></div></blockquote><div style="">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?</div>
</div></div></div></blockquote><br></div><div>MCContext should definitely not be calling getenv. Yes, it should just be an argument to the ctor, or perhaps a "setter" method on mccontext, used by clients who care.</div><div><br></div><div>-Chris</div><br></body></html>