<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, Oct 20, 2018 at 5:08 PM Nicolai <span class="" id=":1gp.1" tabindex="-1" style="">Hähnle</span> via <span class="" id=":1gp.2" tabindex="-1" style="">llvm</span>-<span class="" id=":1gp.3" tabindex="-1" style="">dev</span> <<span class="" id=":1gp.4" tabindex="-1" style="">llvm</span>-<span class="" id=":1gp.5" tabindex="-1" style="">dev</span>@lists.<span class="" id=":1gp.6" tabindex="-1" style="">llvm</span>.org> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yevgeny,<br>
<br>Just to make sure I'm understanding this correctly: When a thread has a <br>
non-null option context, then options set in the global context will <br>
have no effect at all for that thread. Right? (That's what I would <br>
expect and what makes sense to me.)<br><br></blockquote><div>Yes, but the global context has no effect on your thread only for those options that have been changed in this thread's context.</div><div>That is because a thread local copy of an option is created in the current thread context when this option is set by this thread or another thread with the same option context. If the option has not been set then its global value is used.</div><div>For your case, I would suggest that you explicitly set a new thread option context for every thread (or thread group) that uses <span class="" id=":1gp.7" tabindex="-1" style="">LLVM</span>. This way the threads/groups will not affect each other and will use the options in the copy-on-write way.</div><div>May be it makes sense to try playing with the tests in the patch to better understand the use model.</div><div><br></div><div>Thanks.</div><div>-Yevgeny Rouban</div><div><br></div></div></div>