Re: Clarification about auto-revert-mode and inotify

[Stefan Monnier]

>> That's better, indeed.  The other problem I see with just increasing the
>> timer frequency is the effect it has on those files not covered by
>> inotify (e.g. remote files).
> Maybe we should have 2 separate options, then (if we are going to
> reduce the default time interval).

Maybe we should yes.

> My point is that scalability is not affected only by the number of
> buffers that have auto-revert turned on.  In a busy directory, we will
> have to process many notifications that eventually turn out to be for
> files we don't care about.  Processing each notification requires
> looping through all the buffers, to find those which have auto-revert
> turned on.

No, we use a hash table to associate buffers to particular
notify-descriptors so we only go through the buffers that do have
auto-revert enabled and that can be affected by changes in this
directory.  That can still be a lot of buffers, but is still much better
and that loop can be improved (e.g. hoisting the file-name-nondirectory
out of the loop).

> (We do cut short the search when we find the first client
> buffer for a particular notification, but that doesn't help with
> notifications for which there is no client buffer.)

Yes, I don't think this short cut makes any difference.

> And what about the scalability of the change proposed by Dima?  It
> causes each auto-reverted buffer to have its own timer, which would
> mean dozens of timers running to support 100 buffers.  Wouldn't that
> slow down Emacs's input loop?

Oh, yes, a timer per buffer would be a bad idea.

> And, of course, the revert operation itself also uses up CPU.  The
> relatively long interval we use now in effect collapses all the
> modifications to a file during the last 5 sec into a single revert.
> Reverting "immediately" will revert on each notification, which could
> be quite a lot.  How will that affect scalability?

That is indeed a good reason to throttle updates.

> Bottom line, if scalability is a requirement, we need to have a
> broader picture, and then consider the possible solutions based on
> notifications in light of that.

To me the main goals should be:
- *very* low resource use when the system is idle.
- prompt updates after a "one time" change.
- keep Emacs responsive even in case of constant updates.


        Stefan