<div dir="ltr">There are two possible problems with Dave&#39;s benchmark:<div><br></div><div>1) On my system setting TCP_NODELAY option on the accepted server socket changes results dramatically.</div><div>2) What category of socket servers is dave&#39;s spin() function intended to simulate?</div>
<div><br></div><div>In a server which involves CPU intensive work in response to a socket request the behavior may be significantly different.</div><div>In such a system, high CPU load will significantly reduce socket responsiveness which in turn will reduce CPU load and increase socket responsiveness.</div>
<div><br></div><div>Testing with a modified server that reflects the above indicates the new GIL behaves just fine in terms of throughput.</div><div>So a change to the GIL may not be required at all.</div><div><br></div><div>
There is still the question of latency - a single request which takes long time to process will affect the latency of other &quot;small&quot; requests. However, it can be argued if such a scenario is practical, or if modifying the GIL is the solution.</div>
<div><br></div><div>If a change is still required, then I vote for the simpler approach - that of having a special macro for socket code.</div><div>I remember there was reluctance in the past to repeat the OS scheduling functionality and for a good reason.</div>
<div><br></div><div>Nir</div><div><br><br><div class="gmail_quote">On Sat, Mar 13, 2010 at 11:46 PM, Antoine Pitrou <span dir="ltr">&lt;<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hello,<br>
<br>
As some of you may know, Dave Beazley recently exhibited a situation<br>
where the new GIL shows quite a poor behaviour (the old GIL isn&#39;t very<br>
good either, but still a little better). This issue is followed in<br>
<a href="http://bugs.python.org/issue7946" target="_blank">http://bugs.python.org/issue7946</a><br>
<br>
This situation is when an IO-bound thread wants to process a lot of<br>
incoming packets, while one (or several) CPU-bound thread is also<br>
running. Each time the IO-bound thread releases the GIL, the CPU-bound<br>
thread gets it and keeps holding it for at least 5 milliseconds<br>
(default setting), which limits the number of individual packets which<br>
can be recv()&#39;ed and processed per second.<br>
<br>
I have proposed two mechanisms, based on the same idea: IO-bound<br>
threads should be able to steal the GIL very quickly, rather than<br>
having to wait for the whole &quot;thread switching interval&quot; (again, 5 ms<br>
by default). They differ in how they detect an &quot;IO-bound threads&quot;:<br>
<br>
- the first mechanism is actually the same mechanism which was<br>
  embodied in the original new GIL patch before being removed. In this<br>
  approach, IO methods (such as socket.read() in socketmodule.c)<br>
  releasing the GIL must use a separate C macro when trying to get the<br>
  GIL back again.<br>
<br>
- the second mechanism dynamically computes the &quot;interactiveness&quot; of a<br>
  thread and allows interactive threads to steal the GIL quickly. In<br>
  this approach, IO methods don&#39;t have to be modified at all.<br>
<br>
Both approaches show similar benchmark results (for the benchmarks<br>
that I know of) and basically fix the issue put forward by Dave Beazley.<br>
<br>
Any thoughts?<br>
<br>
Regards<br>
<br>
Antoine.<br>
<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/nir%40winpdb.org" target="_blank">http://mail.python.org/mailman/options/python-dev/nir%40winpdb.org</a><br>
</blockquote></div><br></div></div>