<br><br><div><span class="gmail_quote">On 9/17/06, <b class="gmail_sendername">Nick Coghlan</b> <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Andre Meyer wrote:<br>> While I understand the difficulties in removing the GIL and the<br>> potential negative effect on single-threaded applications I would very<br>> much encourage discussion to seriously consider removing the GIL (maybe
<br>> optionally) in Py3k. If not, what alternatives would you suggest?<br><br>Brett Cannon's sandboxing work (which aims to provide first-class support for<br>multiple interpreters in the same process for security reasons) also seems
<br>like a potentially fruitful approach to distributing processing to multiple cores:<br> - use threads to perform blocking I/O in parallel<br> - use multiple interpreters to perform Python execution in parallel</blockquote>
<div><br>Possibly, but as it stands now interpreters just execute in their own Python thread, so there is no real performance boost. Without the GIL shifting over to per interpreter instead of per process there is going to be the same performance problems as with Python threads. And changing that would be hard since objects can be shared between multiple interpreters.
<br></div><br>-Brett<br></div>