input procs can starve the application of X events
Submitted by Chris Beauregard
Assigned to Xorg Project Team
Created attachment 101434 test cases for XtAppMainLoop input proc starvation
Apologies about the version... Debian makes it hard to identify the specific libXt version. This is against whatever is currently shipping on wheezy and trusty.
In a nutshell, if you add an input proc against an input source which continuously feeds input (i.e. /dev/zero), X events will not be processed while input is arriving. If you have an application which was designed around the idea of opening an input stream and still handling X events (i.e. including a "Stop" button) then you've got a problem.
I'm fairly sure this is a direct consequence of https://bugs.freedesktop.org/show_bug.cgi?id=34715
If I replace XtAppMainLoop() with the previous event handler (using XtAppNextEvent()/XtDispatchEvent() rather than XtAppProcessEvent()), things work as expected.
In http://cgit.freedesktop.org/xorg/lib/libXt/tree/src/NextEvent.c, the XtAppProcessEvent() flow handles signals, timers, and alternate inputs first, and returns on the first one it finds. If it doesn't find anything, only then will it check for events. In the case of an always-available input source, it'll never reach the X event queue.
XtAppNextEvent(), on the other hand, is a simple loop of DoOtherSources() and check the X event queue. So it will (albeit slowly) process the X event queue even if an input source is spamming it.
See the attached test cases. test1.c uses the XtAppMainLoop(), and once you click "Start" the application ignores any further events. test2.c uses the old style main loop, and it works as one might expect.
My feeling is the change in #34715 seems reasonable given the problem it was trying to solve, but if you're going to do that then XtAppProcessEvent() needs to be changed to ensure that any single input source doesn't starve all the others, or at least adjust the priority of the input sources so starvation is less likely (input handlers last, most likely; if you've got enough signals, timers, or X events to starve anything else, you've got bigger problems). Of course, someone needs to decide what to do about work procs (is work proc starvation a concern or not).
Attachment 101434, "test cases for XtAppMainLoop input proc starvation":
Version: 7.7 (2012.06)