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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
