System-wide keyboard event delay if main thread is blocked (Windows)
Steps to reproduce
- In any program, halt the main thread (i.e.
g_usleep()
orsleep()
) for a significant amount of time, preferably on the order of seconds. - Try to type in any text-editing program / use anything that requires keyboard input.
A more-or-less minimal example:
int main(int argc, char ** argv) {
gtk_init_check(&argc, &argv);
// When run, starves the main thread by not iterating
// on the main glib context for 10 seconds
g_usleep(10000*1000);
gtk_main();
return 0;
}
The timing of when the blocking happens doesn't seem relevant as long as it's after gtk_init()
.
Current behavior
Keyboard events on the system in any program produce a significant delay while the bug is active. Mouse events seem to be fine, however.
Expected outcome
Keyboard input processing should not be affected in a general context. The logic controlling or affecting input queue and winapi message handling should be restricted the behavior of the program itself at runtime rather than affecting the user's ability to utilize other programs.
Version information
GTK+ 3.22.30 (packaged by the MSYS2 project)
Windows 7 (confirmed on Windows 10 as well)
Additional information
- Have not observed this behavior on Linux systems.
- I'm not deeply familiar with winapi and its inner workings, but this seems to be related to the message queue in Windows being "backed up" due to
g_main_context_iteration()
not being called to process the requests that should normally be handled in a GTK+ update frame. The system then allows messages to happen again after some limit or timeout is reached. - Since this problem seems to be from blocking the main thread in general rather than something specific to
sleep
ing, I would expect similar behavior in programs where a computation-heavy callback, for example, takes an unexpectedly significant amount of time for an atomic function call to finish. - This problem did not occur in the "old stable" GTK+ 3.6.4.
- The issue does not happen if only glib is used.
- No relevant GTK+ messages available.