Re: inotify-based file notifications missing sometimes

[Eli Zaretskii]

> From: Dima Kogan <address@hidden>
> Cc: address@hidden
> Date: Sat, 25 Oct 2014 01:27:43 -0700
> 
> > But you are not saying that having more than one file in the same
> > directory under auto-revert-mode doesn't work for this reason, are
> > you?  Because I just tried, and it does work, because autorevert.el
> > does handle this situation.
> 
> I'm not saying that largely because this thread is explicitly not about
> auto-revert-mode. autorevert.el likely handles this because it was
> originally written to not use inotify at all (and is still that way for
> remote files), and likely makes more thorough checks.

The file-notification support in autorevert _was_ added when inotify
became supported.  According to my reading of the related code, its
handling of notifications is explicitly designed to handle the
situation where notifications about several files come through the
same watch descriptor.  This code was not in autorevert.el before file
notifications were added to Emacs.

> The patch in the other thread makes auto-revert-mode event based,
> and is broken by the issue described in this thread.

Nitpicking: nothing in Emacs is event based (well, maybe except of a
few signals; but even there, signals that need non-trivial processing
just set a flag that is examined later).  Everything goes through the
Emacs input queue.  The only reason you might think file notifications
(and other events) are handled "immediately" is because Emacs checks
the input queue very frequently, at least when it's not busy with some
lengthy calculation.

> The problem is that we provide utility functions in filenotify.el that
> claim to do something and do not do it. More to the point of what I'm
> doing, I want to fix the event-based auto-revert, as implemented in the
> patch I sent to the list a few hours ago. The patch is fine, I think,
> but the issue described HERE breaks it.

I think the solution to that should be in your patch.

We could, of course, consider modifications in filenotify.el as well,
but my gut feeling, based on past discussions, is that it would be
more ugly, due to the need to support several different use cases and
several back-ends.

> > Just to clarify: filenotify.el is infrastructure that currently
> > (AFAIK) has only one user -- autorevert.el.  At the time the file
> > notifications were introduced, there were many discussions about how
> > best to design this infrastructure.  Eventually, the conclusion was
> > that we should make these decisions as we go, as we add user-level
> > features based on the notifications.  So for now, filenotify.el
> > reflects the needs of its single user, and with that user it does its
> > job.  If there are additional needs and goals not covered by that,
> > they should be explicitly stated, and then filenotify.el might need to
> > be extended/modified to cover them.
> 
> OK. That is reasonable. I have no problems with the filenotify.el API at
> all, it's just that the API description is not being respected.

I guess some documentation fixes are in order, then.

> By the way, the other filenotify.el backend for linux (gfile) has an
> issue as well. Running the same test with it DOES produce events for
> both files, but events come throught only when the user touches emacs.
> So when the files are modified, nothing shows up in *Messages*, but
> pressing any key in the emacs window makes them pop up. I haven't looked
> into the cause of that yet, but intend to shortly.

Welcome to the black art known as file notifications.  Each of the 3
available back-ends has its own "issues".  The current version of
filenotify.el tries to paper over them, but I'm quite sure it doesn't
yet do a perfect job, except when used through autorevert.el.  We
simply don't yet have enough experience with that.