readline timeout too long for async gfx use

[pmp-p]

BPO	35243
Nosy	@Yhg1s, @pmp-p

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2018-11-14.08:08:28.573>
labels = ['extension-modules', '3.8', '3.9', '3.10', 'performance']
title = 'readline timeout too long for async gfx use'
updated_at = <Date 2020-09-14.23:11:05.822>
user = 'https://github.com/pmp-p'

bugs.python.org fields:

activity = <Date 2020-09-14.23:11:05.822>
actor = 'pmpp'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Extension Modules']
creation = <Date 2018-11-14.08:08:28.573>
creator = 'pmpp'
dependencies = []
files = []
hgrepos = []
issue_num = 35243
keywords = []
message_count = 1.0
messages = ['329891']
nosy_count = 2.0
nosy_names = ['twouters', 'pmpp']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'performance'
url = 'https://bugs.python.org/issue35243'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[pmp-p]

unlike https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame which is fires about each 1/60 second : the callback for gui via PyOS_InputHook is as long as 0.1 second.

cpython/Modules/readline.c

Line 1192 in 8e0b05e

{ struct timeval timeout = {0, 100000}; /* 0.1 seconds */

using repl asyncronously with such a timer is a bad experience when using async opengl based gui : asyncio loop steps should be able to be served at vsync speed which is not actually possible because of hardcoded value.

0.008 seconds would not be so bad, best would be plan next call to hit T+ frametime ( with a default to 0.016 ) each pass inside the loop.

a use case for python would be panda3d and its various gui.

real life example in other mainstream language : the javascript repl in the browser console.