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

[Mattias Engdegård]

24 apr. 2019 kl. 20.58 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> The polling was added for a reason, and the reason was not reliability
> of the notifications.  The reason is hinted upon in this comment:
> 
>  ;; If we have file notifications, we want to update the auto-revert buffers
>  ;; immediately when a notification occurs. Since file updates can happen very
>  ;; often, we want to skip some revert operations so that we don't spend all 
> our
>  ;; time reverting the buffer.
>  ;;
>  ;; We do this by reverting immediately in response to the first in a flurry 
> of
>  ;; notifications. We suppress subsequent notifications until the next time
>  ;; `auto-revert-buffers' is called (this happens on a timer with a period 
> set by
>  ;; `auto-revert-interval').

Thank you, interesting! In any case, that should not be a problem: the patch 
takes care of it in a more principled way, by the means of a timer. Currently, 
auto-revert is inhibited until next periodic poll, which can be anything 
between 0 and 5 seconds away. The patch sets this to a fixed value (2.5 s).

> If you look at bug reports and discussions around the time this
> comment was written, you will find the descriptions of the use cases
> that caused this design.  AFAIR, the main problem was with inotify,
> not with w32notify.

The inotify problems at the time seem to have stemmed from not using unique 
notification descriptors. This was fixed some time ago (158bb8555d etc, 
bug#26126).

> If you imply that Samba drives can be identified by the syntax of the
> file name alone, then I don't think this is a valid assumption.  A
> certain drive letter can be mapped to a Samba volume, and we can never
> know that by looking just at the file name.

Certainly, but the intent was to add something like the attempts to identify 
network file systems on Unix machines:

   "^" (regexp-opt '("/afs/" "/media/" "/mnt" "/net/" "/tmp_mnt/"))

If that regexp is acceptable as rough heuristics on Unix, surely something like 
the regexp proposed, matching \\SOMETHING\, shouldn't be out of the question on 
Windows? Full precision cannot be attained, as you point out, but perhaps we 
can make life easier for the user.

> More generally, auto-revert-notify-exclude-dir-regexp is for any
> situation where a filesystem doesn't cause notifications.  You will
> find caveats about such issues in the documentation of every
> notification system we support.

Yes, that is my understanding as well. Are you arguing that the default value 
of auto-revert-notify-exclude-dir-regexp should not be extended in the proposed 
way, or that the variable is fundamentally incompatible with the patch?