[Python-Dev] "Fixing" the new GIL
Nick Coghlan
ncoghlan at gmail.com
Tue Mar 16 23:08:14 CET 2010
Kristján Valur Jónsson wrote:
> We have never had high priority for IO threads in
> python (and its not-by-design round robin scheduler on single core
> cpus) and it is unclear why that should be required now as a fix.
David explained that in the issue tracker - 2.x typically doesn't do
that much work per bytecode instruction, so the interpreter releases and
reacquires the GIL far more frequently in a CPU-bound thread than it
does under the new time-based check interval.
The current settings mean we have less GIL overhead in the normal case,
but worse worst-case I/O latency.
There are two fairly straightforward ways to handle that:
- cut the check interval duration drastically (trading GIL overhead for
I/O responsiveness, as in 2.x)
- add some form of I/O thread prioritisation, such as Antoine's gilinter
patch (which automatically identifies and prioritises "interactive"
threads at the cost of a dozen or so additional lines of C code and a
small amount of overhead on GIL context switches to adjust thread
interactivity counters).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
More information about the Python-Dev
mailing list