This is a very long-running issue, that has been discussed many times. Here are the two sides to keeping the gil or removing it:<br><br>Remove the GIL:<br><ul><li>True multi-threaded programming</li><li>Scalable performance across a multi-core machine</li>
<li>Unfortunately, this causes a slow-down in single core/thread performance</li><li>Most of the slow down comes from Python's Reference counting, as every function is supposed to increase and decrease the references... which leads to a lot of synchronization and checking of locks.</li>
<li>It makes the core interpreter much more complex<br></li></ul>Keeping the GIL:<br><ul><li>Processes should be used instead of threads. Look at Erlang, THE model of concurrency. It uses a process model for concurrency and message passing, rather than threads. This means you avoid deadlocks, livelocks, race conditions(not entirely, but they are reduced)</li>
<li>C extensions can still gain really impressive multi-threaded performance. My C extension, a wrapper around ffmpeg, releases the GIL for 90% or so of its processing time, so all other threads are still extremely responsive. </li>
<li>It allows python to stay simple, understandable, and offer good performance, if you know how to use it properly.</li></ul>Basically the two sides are that you it ends up slowing things down, it makes the interpreter more complex vs you should use processes instead, and be smart about how you use the GIL.<br>
<br>-Tyler<br><div class="gmail_quote">On Fri, Jun 19, 2009 at 2:52 AM, Jure Erznožnik <span dir="ltr"><<a href="mailto:jure.erznoznik@gmail.com">jure.erznoznik@gmail.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;">
See here for introduction:<br>
<a href="http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91" target="_blank">http://groups.google.si/group/comp.lang.python/browse_thread/thread/370f8a1747f0fb91</a><br>
<br>
Digging through my problem, I discovered Python isn't exactly thread<br>
safe and to solve the issue, there's this Global Interpreter Lock<br>
(GIL) in place.<br>
Effectively, this causes the interpreter to utilize one core when<br>
threading is not used and .95 of a core when threading is utilized.<br>
<br>
Is there any work in progess on core Python modules that will<br>
permanently resolve this issue?<br>
Is there any other way to work around the issue aside from forking new<br>
processes or using something else?<br>
<font color="#888888">--<br>
<a href="http://mail.python.org/mailman/listinfo/python-list" target="_blank">http://mail.python.org/mailman/listinfo/python-list</a><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Visit my blog at <a href="http://oddco.ca/zeroth/zblog">http://oddco.ca/zeroth/zblog</a><br>