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

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> > 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?

After all, Emacs is still a text editor, isn't it? Key strokes and mouse
events are the most important events, I believe.

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.

>> 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.

Yep. And Ian is also on the same way, AFAIU.

Best regards, Michael.