[Python-Dev] "Fixing" the new GIL

Antoine Pitrou solipsis at pitrou.net
Sat Mar 13 22:46:51 CET 2010


As some of you may know, Dave Beazley recently exhibited a situation
where the new GIL shows quite a poor behaviour (the old GIL isn't very
good either, but still a little better). This issue is followed in

This situation is when an IO-bound thread wants to process a lot of
incoming packets, while one (or several) CPU-bound thread is also
running. Each time the IO-bound thread releases the GIL, the CPU-bound
thread gets it and keeps holding it for at least 5 milliseconds
(default setting), which limits the number of individual packets which
can be recv()'ed and processed per second.

I have proposed two mechanisms, based on the same idea: IO-bound
threads should be able to steal the GIL very quickly, rather than
having to wait for the whole "thread switching interval" (again, 5 ms
by default). They differ in how they detect an "IO-bound threads":

- the first mechanism is actually the same mechanism which was
  embodied in the original new GIL patch before being removed. In this
  approach, IO methods (such as socket.read() in socketmodule.c)
  releasing the GIL must use a separate C macro when trying to get the
  GIL back again.

- the second mechanism dynamically computes the "interactiveness" of a
  thread and allows interactive threads to steal the GIL quickly. In
  this approach, IO methods don't have to be modified at all.

Both approaches show similar benchmark results (for the benchmarks
that I know of) and basically fix the issue put forward by Dave Beazley.

Any thoughts?



More information about the Python-Dev mailing list