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

[Eli Zaretskii]

> 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 18:12:12 +0100
> 
> >> "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?
> 
> After all, Emacs is still a text editor, isn't it? Key strokes and mouse
> events are the most important events, I believe.

I agree, but since window-system events come from the same source as
keys and mouse, we don't have a good way of processing "keys and mouse
first", do we?  We can only process everything that comes from the
read_socket_hook before file notification (which would mean "keys,
mouse, and window-system events first"), or the other way around.

So the question whether a window-system event is more or less
important than a file-notification event still stands, and has no easy
solution if we start reading events from two queues instead of just
one.

> As rule of thumb, I would discriminate all events, which can aarive as
> burst, and which are already known to be lost sometimes. D-Bus and file
> notification events. If we classify other events into this category - no
> problem.

That's okay (and note that w32notify already does drop excess events
on the floor).