Hi,<br><br><div class="gmail_quote">On Fri, Jul 24, 2009 at 7:03 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
On Jul 24, 2009, at 9:30 AM, Duncan Sands wrote:<br>
<br>
>> The ones that don't can be static functions on the type class that<br>
>> take a context.  For example, Type::Int32Ty needs to become a<br>
>> function<br>
>> that takes a context at some point.<br>
><br>
> Why is that?  If it is read-only then it should be possible to share<br>
> it between all threads.<br>
<br>
</div>Type's aren't readonly, see all the mutable fields in them.  While we<br>
might be able to get away with a special case for these, I'd rather<br>
have a clean model where no IR is shared across contexts.<br>
<font color="#888888"></font></blockquote><div><br>I'm sorry if I am  being dense so please bear with me.<br><br>Assuming that I have a threaded JIT server which has an llvmContext object <br>on the stack of every JITting thread in the server. <br>
<br><p style="margin: 0px; text-indent: 0px;">When using the 2.5. API like:<br></p><p style="margin: 0px; text-indent: 0px;"></p><p style="margin: 0px; text-indent: 0px;"></p>
<p style="margin: 0px; text-indent: 0px;">   C = llvm::ConstantInt::get(llvm::Type::Int32Ty, 0);</p><br>I need to assume that there exists some global llvmContext object which holds<br>the predefined llvm types.<br><br>Does this entail that in my threaded server I need to create new  types for<br>
llvm::Type::Int32Ty and the like,  which are associated with the llvm::Context on the stack?<br>Or will things work correctly when mixing values created using the global<br>context and other stuff created using the context object on the stack of threads?<br>
<br>I guess that I am trying to say that it seems to me that the 2.5 API is more<br>prone to  synchronization issues than the interim 2.6 version of the API.<br>The reason for this assumtion is that it seemed clear which context<br>
object governed the lifetime of all llvm related objects.<br><br>So why not support the newer interim 2.6 API as well?<br><br> Anybody willing to spell  out what the rules will be for using<br>LLVM for multi-threaded JITting? <br>
<br>Thanks.<br><br>Kind regards,<br>Maurice<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><font color="#888888"><br>
-Chris<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</div></div></blockquote></div><br>