bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Po Lu
Subject: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy
Date: Sat, 22 Jan 2022 08:38:22 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Ian Jackson <ijackson@chiark.greenend.org.uk> writes:

> I experienced a bug where my Emacs (Debian's emacs-lucid) would lose
> keystrokes under pathological conditions.  I tracked this down to the
> keyboard input buffer filling up with inotify events.
>
> The attached patches have been rebased onto emacs-28 (fbc9b121e062)
> and I have tested before-and-after versions in parallel to verify that
> the bug appears in the upstream branch and has been fixed with my
> patches.
>
> The bug was really quite severe in my (rather abusive) situation, with
> Debian's emacs-lucid 26.1.  With the upstream emacs-28 branch it
> requires more effort, and loses fewer keys.  I suspect that some more
> sophisticated approach to inotify requests means it's harder to get
> the buffer to fill up with the newer version.  Unfortunately I am not
> able to share my whole repro, but a key part is to visit the output
> file from this
>   while yes | dd of=t bs=1 count=1000000; do : ;
> with global-auto-revert-mode enabled.
>
> With my patches it is still possible to get emacs to perform very
> poorly by abusing it this way, but at least all the keys arrive
> eventually.  I added some FIXMEs for further work that would be good,
> but is not critical to fixing the bug.

I would rather not allocate anything on the heap to hold inotify events.

The best thing to do, IMO, would be to simply not store any
FILE_NOTIFY_EVENTS if the keyboard buffer is full, which shouldn't
affect normal use of file notifications, and would result in less change
to the keyboard code.

Thanks.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]