bug#35418: [PATCH] Don't poll auto-revert files that use notification

["Mattias Engdegård" <mattiase@acm.org>]

29 apr. 2019 kl. 09.19 skrev Michael Albinus <michael.albinus@gmx.de>:
> 
> By design, in filenotify.el, we want see only events which are related
> to the file *name*. If you want to be notified for both buffers, you
> need to watch both file (names).

Well yes, but you want a change to the file to be reported for both buffers, even if they watch different names, right?

Otherwise, it wouldn't make sense at all. If someone is watching a file, surely it is because changes to the contents of that file are of interest? Why would the name employed to carry out the changes matter?

I'm quite sure there is a simple misunderstanding here; probably my fault. And again, I don't think it matters much in practice since users are unlikely to have buffers for different hard links to the same file. Let's not waste too much time on this.

>> However, with the kqueue back-end, file-notify watches do trigger for
>> both, as expected.
> 
> Hmm, this is inconsistent. Worth a buig report?

Not really, because (a) multiple hard links are rare, (b) even more rare in Emacs, and (c) inotify isn't used that way by auto-revert (the directory is watched, not the files).

> It was a design decision, that filenotify.el implements directory
> watching. Since kqueue does not support this, it must be emulated, somehow.

Well, auto-revert only uses filenotify.el for watching changes to files (that is, the data corresponding to the names). How filenotify does that isn't very important. I suppose watching directories when possible has the advantages:

+ fewer (kernel-level) descriptors used if there are multiple files of interest in the same directory
+ notification about re-created previously removed files

with at least one disadvantage:

- changes to files not of interest have to be considered and rejected, spending more CPU and power. This can be non-trivial; consider looking at a single non-changing file in a very busy directory with files being added and removed all the time.

For kqueue and w32notify (and FSEvent) there isn't much choice.

>> What other reasons are you thinking about?
> 
> The reasons you have already quoted somewhere else: sometimes, file
> notification is not applicable; there are not enough descriptors left; a
> file might have been deleted; a file notification process has been
> killed silently; you name it ...

Thank you. Most of those cases should not cause any trouble -- except unreliable file notification processes, but since `auto-revert-remote-files' defaults to nil, it didn't look like a serious problem.