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

[Eli Zaretskii]

> From: Ian Jackson <ijackson@chiark.greenend.org.uk>
> Date: Sat, 22 Jan 2022 19:34:33 +0000
> Cc: 53432@debbugs.gnu.org
> 
> Eli Zaretskii writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input 
> when inotify is too busy"):
> > Thanks.  I doubt that we want to complicate our input handling this
> > way on behalf of "abusing" inotify.  File notifications are known not
> > to be scalable enough to support global-auto-revert-mode well.
> 
> The problem is that keystrokes (and file notifications) get lost.  I
> don't think we should be shipping code that can do that.  Even if it
> only does it if you are working on a program whose build system writes
> a lot of files, and/or have a slow computer, and/or are unlucky.  Note
> that magit turns on global-auto-revert-mode so this is a very common
> configuration.  Loss of file updates is also a real problem, becuase
> it can lead to the user editing an old version of a file.

Which is why we recommend turning off file-notifications when you turn
on global-auto-revert-mode.

> The fact that I have to "abuse" things to demonstrate the race, does
> not mean that it's not a real bug.  That's in the nature of race bugs.

What race is that?  This processing is going on in a single thread, so
how can there be any races?

> > 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.
> 
> Wouldn't that lead to file notifications getting lost ?

Yes, but inotify (and other similar features on other OSes) doesn't
guarantee that all the events be delivered when there are many of
them.  Which is one more reason not to use file notifications to watch
too many files/directories.  This stuff isn't scalable enough.

> Eli:
> > In any case, installing this on the emacs-28 branch is out of the
> > question: it's too late for that.  We may install some variant of this
> > on master, after discussing how best to handle this.  Po Lu's
> > suggestion to stop processing inotify events sounds better to me.
> 
> I was advised by a friend that I ought to send patches against
> the emacs-28 branch, so I did that.  Indeed, CONTRIBUTING says
> 
>   If you are fixing a bug that exists in the current release, you should
>   generally commit it to the release branch;

It also says, right after that

                                                      However, when the
  release branch is for Emacs version NN.2 and later, or when it is for
  Emacs version NN.1 that is in the very last stages of its pretest,
  that branch is considered to be in a feature freeze: only bug fixes
  that are "safe" or are fixing major problems should go to the release
  branch, the rest should be committed to the master branch.  This is so
  to avoid destabilizing the next Emacs release.  If you are unsure
  whether your bug fix is "safe" enough for the release branch, ask on
  the emacs-devel mailing list.

> > > I hope the commit messages are in the expected format.  I think I
> > > probably have GNU copyright paperwork on file already, perhaps under a
> > > different email address.
> > 
> > I don't see your name or email address on file, so maybe they are both
> > different?
> 
> My name hasn't changed.  But I'm happy to do the paperwork (even if it
> would be "again").  If it did happen, it will have been a long long
> time ago.

Sorry, I don't see your name there.  I just rechecked.