<div dir="ltr">There are two possible problems with Dave'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'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 "small" 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"><<a href="mailto:solipsis@pitrou.net">solipsis@pitrou.net</a>></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'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()'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 "thread switching interval" (again, 5 ms<br>
by default). They differ in how they detect an "IO-bound threads":<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 "interactiveness" of a<br>
thread and allows interactive threads to steal the GIL quickly. In<br>
this approach, IO methods don'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>