[Python-Dev] "Fixing" the new GIL

[Nir Aides]

inline:

On Sun, Mar 14, 2010 at 3:54 PM, Peter Portante
<peter.a.portante at gmail.com>wrote:

>  On 3/14/10 7:31 AM, "Nir Aides" <nir at winpdb.org> wrote:
>
> There are two possible problems with Dave's benchmark:
>
> 1) On my system setting TCP_NODELAY option on the accepted server socket
> changes results dramatically.
>
> Could you document what you saw and explain how you think TCP_NODELAY makes
> a difference, including what kind of system you ran your tests and what the
> application was that demonstrates those dramatic results?
>

I first disabled the call to spin() but client running time remained around
30 seconds.
I then added TCP_NODELAY and running time dropped to a few dozen
milliseconds for the entire no-spin run.
The system is Ubuntu Karmic 64bit with latest revision of python 3.2.

2) What category of socket servers is dave's spin() function intended to
> simulate?
>
> What is the problem you are trying to get at with this question?
>
> Does Dave’ spin() function have to have a category? Or perhaps the question
> is, for these solutions, what category of application do they hurt? Perhaps
> we can look at the solutions as general, but consider their impact in
> various categories.
>

In Dave's code sample, spin() is loading the CPU regardless of
requests. This may demonstrate how short IO bound requests will behave while
the server is processing a long Python-algorithmic CPU intensive request, or
an ongoing CPU intensive task unrelated to incoming requests. However is
this typical for socket servers?

If you change the sample server code to start a CPU bound thread with work X
for each incoming request you will see different behavior.

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.
>
> Perhaps Dave already documented this effect in his visualizations, no?
>

Naturally. I did not imply otherwise. His analysis is brilliant.


> If a change is still required, then I vote for the simpler approach - that
> of having a special macro for socket code.
>
> What is that simpler approach? How would that special macro work?
>

The special macro for socket code is one of the alternatives proposed by
Antoine above.

However, thinking about it again, with this approach as soon as the new
incoming request tries to read a file, query the DB, decompress some data or
do anything which releases the GIL, it goes back to square one. no?

I remember there was reluctance in the past to repeat the OS scheduling
> functionality and for a good reason.
>
>
> In what ways do we consider the CPython interpreter to be different than
> another application that has multiple threads and contention for one
> resource? Perhaps we have a unique problem among all other user space
> applications. Perhaps we don’t.
>

I think a rule of thumb is to protect a resource (typically a data
structure), as tightly as possible, avoiding for example locking across
function calls, etc, if possible. In contrast CPython is "locked" the entire
time.

As for the behavior of the GIL, how are the proposed solutions repeating OS
> scheduling functionality?
>

Dave discussed this in his analysis.

Nir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100314/200248df/attachment-0001.html>