[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy
From: |
Michael Albinus |
Subject: |
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] |
Date: |
Mon, 24 Jan 2022 18:12:12 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
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.
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], (continued)
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/22
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/23
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Eli Zaretskii, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Eli Zaretskii, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages],
Michael Albinus <=
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Eli Zaretskii, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Ian Jackson, 2022/01/24
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Michael Albinus, 2022/01/25
- bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages], Po Lu, 2022/01/23
bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy, Eli Zaretskii, 2022/01/22