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 ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4