[Python-Dev] "Fixing" the new GIL

[Nick Coghlan]

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
---------------------------------------------------------------