Re: [PATCH] Added inotify support.

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Date: Mon, 08 Oct 2012 16:07:18 +0900
> Cc: Nix <address@hidden>, Óscar Fuentes <address@hidden>,
>       address@hidden
> 
> According to nix, inotify is unreliable, end of discussion.
> 
> If so, it may make sense to back up inotify with polling, although at
> a greatly reduced rate.  Also, files may get moved across filesystems
> which support different mechanisms, etc, etc.  So allowing different
> files to get notifications in different ways, and perhaps even
> changing backends on the fly may be useful/necessary for maximum
> reliability.

If one wants a 100% reliability, polling cannot be done at slower
rates without degrading response times.  Some applications might not
like the long response times.  And of course, you won't know when the
notifications are less reliable than you would like to, so selectively
increasing the polling rate in those problematic cases seems
impossible.

Moreover, both inotify and the equivalent Windows APIs are documented
to lose notifications on a busy filesystem, so even a perfectly local
file/directory cannot be watched with 100% reliability.

And that is even before we think about the effects of the internal
Emacs mechanisms of handling these events.  E.g., if there's a lot of
input from the keyboard and the window system, and if some heavy Lisp
is running, it is quite possible to have the file-notification event
be stuck in limbo for some time, before Emacs examines it and takes
action.

IOW, this will work well "most of the time", but that's about it.