Hello, 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 http://bugs.python.org/issue7946
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? Regards Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
