[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26973: 26.0.50; sleep-for behavior changes with global-auto-revert-m
bug#26973: 26.0.50; sleep-for behavior changes with global-auto-revert-mode enabled
Sun, 04 Jun 2017 19:20:37 +0300
> From: Andreas Politz <address@hidden>
> Cc: Michael Albinus <address@hidden>, address@hidden, address@hidden,
> 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
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
Or should I try something else? I can easily post the code and the
procedure I used, if that would help clarify the issue.