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

[Po Lu]

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

> I'm not sure what your underlying objection is to this, so I will
> guess: I think you are concerned at the performance implications of
> allocating each time we handle inotify events.  But my proposed code
> does not allocate each time.  It only (re)allocates when it needs a
> bigger buffer than it already has.

The underlying objection is that it's IMHO wrong to allocate anything on
the heap to cater to "abuse" of a feature, in this case inotify.

> Wouldn't that lead to file notifications getting lost ?  I think that
> might result in buffers not being reverted, even though the user has
> global-auto-revert-mode enabled.  As I say that would be a problem,
> because it can end up with the user editing the wrong version of a
> file.  I don't think it is OK.

It can't end up with the user unknowingly editing the wrong version of a
file, because Emacs will ask him:

  foo.h changed on disk; really edit the buffer? (y, n, r or C-h)

When he first tries to edit the file again (the way this works is not
file notifications, but instead comparing stat data.)

There are also builds without file notifications, which are used on many
systems.

> If it is OK for file notifications to get lost, because the need for a
> buffer revert will be picked up another way somehow, then your
> suggestion makes perfect sense to me.  But in that case, I don't
> understand why this code doesn't use a buffer of fixed size (or, at
> least, limited size).

Which code?  The keyboard buffer is the "buffer of fixed size" in the
inotify code.

> Or to put it another way, the current code does a hair-raising thing
> for which the only explanation I could think of was that it is aiming
> never to lose notifications; and if there's a comment somewhere saying
> that the whole inotify system is best-effort, and it's OK for it to
> drop things when stressed, I have missed it.

All file notification systems are "best effort".  At the very least,
dropping events when the keyboard buffer is full would make the behavior
consistent with GLib file notifications, which drops notifications
whenever its own internal buffer fills up.

> If it is OK for it to be best-effort, then I think this needs to be in
> the documentation for inotify-add-watch.  Currently it says
>
>   The watch will look for ASPECT events and
>   invoke CALLBACK when an event occurs.
>
> and there's nothing saying "it might not happen, so you must arrangee
> that this is not the sole way you are looking for changes".  I think
> that'd be an API which would invite programmers to write and ship lost
> event bugs, especially since usually it would work just fine.

It's acceptable for there to be some lossage when confronted by (in your
own words) abuse of a feature.  That is taken for granted, whether or
not it is documented.

Thanks.