bug#26973: 26.0.50; sleep-for behavior changes with global-auto-revert-mode enabled

[Eli Zaretskii <eliz@gnu.org>]

> From: Andreas Politz <politza@hochschule-trier.de>
> Cc: Michael Albinus <michael.albinus@gmx.de>,  26973-done@debbugs.gnu.org,  eggert@cs.ucla.edu,  dgutov@yandex.ru
> Date: Sun, 04 Jun 2017 17:30:15 +0200
> 
> Activating global-auto-revert-mode seems to lead to starvation of the
> collection of output from running processes in an inotify build.
> Inhibiting the generation of open, close and access file-events seems to
> have fixed this problem.

I thought this was inotify-specific, because of the flags used in that
back-end, is that correct?  w32notify uses only the flags specified by
the caller, it doesn't add any flags of its own.

> This lead to the hypotheses that, in case the above types of events are
> reported, reading file-events while idling may by itself lead to the
> generation of more file-events and thus making this process stuck in a
> cycle.

I'm not sure I understand how this could happen.  How can reading
events generate those same events?  Also, is this still related to
invoking sub-processes, or unrelated?

> So, if the above is true, other back-ends could exhibit the same
> behavior, if they were to be instructed to generate open/close/access
> events.  Again, since these events are not used by filenotify.el, it
> would only show, if the back-end is invoked directly,
> e.g. w32notify-add-watch with last-access-time.

So you are saying that if I install a watch for last-access-time
changes, and then change the last-access time of a watched file, I
could have more than one event read by Emacs?  If so, that's not what
I see: I see exactly one event for each change of the last-access
time.

Or should I try something else?  I can easily post the code and the
procedure I used, if that would help clarify the issue.

Thanks.