bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: ijackson@chiark.greenend.org.uk,  luangruo@yahoo.com,
>   53432@debbugs.gnu.org
> Date: Mon, 24 Jan 2022 16:35:17 +0100
> 
> >> The advantage of splitting into "keyboard" and "other things" buffers
> >> would be, that the keyboard buffer doesn't overrun, whatever burst of
> >> D-Bus or file notification events arrives.
> >
> > But the disadvantage is that we will immediately be facing a problem
> > of priority in handling input from more than one source.
> 
> "Key strokes first!" :-)

But it isn't only the key strokes, it's also all the events sent to us
by the window-system.  Now tell me why, say, an expose event should be
more important than a file-notification event, and not the other way
around?

> An alternative approach could be to restrict how many burst events are
> put into the beyboard buffer. Let's say that D-Bus and file notification
> events are allowed to fill that buffer until (KBD_BUFFER_SIZE - 512)
> events (arbitrary number). This would let place for key strokes, mouse
> events and alike.

That's what Po Lu was suggesting, AFAIU: limit the number of queued
file-notification events to not more than some threshold.