New file notification event `stopped'

New file notification event `stopped'

[Michael Albinus]

Hi,

during the work on bug#21432 and bug#21435, we have introduced a new
function `file-notify-valid-p', which tells whether a given monitor is
still active. We have also discussed shortly, whether a monitor should
signal, when it stops its activities. A monitor could cease to work for
different reasons, maybe because it is cancelled (not only by
`file-notify-rm-watch'), maybe because the file/directory to be watched
is deleted, maybe because some internal limits are reached.

Therefore, I propose that a new file notification event `stopped' shall
be added to the file notification events to be raised by a file
notification monitor. This would allow applications to react directly on
this situation. For example, `auto-revert-mode' could switch to polling
then.

The implementation for inotify.c is simple, because it receives already
the native IN_IGNORED event in this case, which could be mapped easily
to the `stopped' event.

The implementation for gfilenotify.c would create such a `stopped'
event, if one of the native events G_FILE_MONITOR_EVENT_DELETED,
G_FILE_MONITOR_EVENT_RENAMED or G_FILE_MONITOR_EVENT_UNMOUNTED was
received, and the file argument is equal to the watched file or
directory.

I hope a simlar mechanism could be implemented for w32notify.c.

Comments?

Best regards, Michael.

Re: New file notification event `stopped'

[Michael Albinus]

Michael Albinus <michael.albinus@gmx.de> writes:

> Hi,

Hi,

> during the work on bug#21432 and bug#21435, we have introduced a new
> function `file-notify-valid-p', which tells whether a given monitor is
> still active. We have also discussed shortly, whether a monitor should
> signal, when it stops its activities. A monitor could cease to work for
> different reasons, maybe because it is cancelled (not only by
> `file-notify-rm-watch'), maybe because the file/directory to be watched
> is deleted, maybe because some internal limits are reached.
>
> Therefore, I propose that a new file notification event `stopped' shall
> be added to the file notification events to be raised by a file
> notification monitor. This would allow applications to react directly on
> this situation. For example, `auto-revert-mode' could switch to polling
> then.
>
> The implementation for inotify.c is simple, because it receives already
> the native IN_IGNORED event in this case, which could be mapped easily
> to the `stopped' event.
>
> The implementation for gfilenotify.c would create such a `stopped'
> event, if one of the native events G_FILE_MONITOR_EVENT_DELETED,
> G_FILE_MONITOR_EVENT_RENAMED or G_FILE_MONITOR_EVENT_UNMOUNTED was
> received, and the file argument is equal to the watched file or
> directory.
>
> I hope a simlar mechanism could be implemented for w32notify.c.
>
> Comments?

Nobody did reply. So I will implement it next days for inotify.c,
gfilenotify.c and Tramp. Maybe Eli could add an implementation for
w32notify.c.

Best regards, Michael.

Re: New file notification event `stopped'

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 10 Oct 2015 12:13:49 +0200
> 
> Nobody did reply.

I did.  Or I thought I did, but now I cannot find my response in the
archives.  Maybe it's my imagination, or maybe it has something to do
with the recent snafu in GNU mailman archives.

Anyway, my response boils down to this: I don't think we should make
notification back-ends invent events that are not reported by the
respective OS facilities.  Doing that is the job of filenotify.el.

In addition, I don't know how to implement this in w32notify.c, at
least not easily.  As I said, when the watched directory is deleted,
the thread that watches exits with an error status, that's all.

What problem should this 'stopped' event solve?  Do we really have a
real-life problem here, and if so, couldn't we solve it in some other
manner?

Re: New file notification event `stopped'

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Nobody did reply.
>
> I did.  Or I thought I did, but now I cannot find my response in the
> archives.  Maybe it's my imagination, or maybe it has something to do
> with the recent snafu in GNU mailman archives.

At least I haven't received an email from you on this topic. Usually,
you Cc the sender of a message.

> Anyway, my response boils down to this: I don't think we should make
> notification back-ends invent events that are not reported by the
> respective OS facilities.  Doing that is the job of filenotify.el.

D'accord. I have no specific plan yet how to implement this in the
backends, maybe they could be kept untouched. I've tried to show that
inotify.c sends already the needed event (`ignored'), and gfilenotify.c
seems also to send useful events about (`deleted', `renamed' and
`unmounted'). Maybe there is indeed nothing to do. If this is also the
case for w32notify.c - even better.

> In addition, I don't know how to implement this in w32notify.c, at
> least not easily.  As I said, when the watched directory is deleted,
> the thread that watches exits with an error status, that's all.

But isn't there at least the `removed' event? Or is it just for files of
the watched directory, and not the directory itself?

In the latter case, we would need a trigger indeed. Maybe sending an
additional `removed' event for the directory could be an option?

> What problem should this 'stopped' event solve?  Do we really have a
> real-life problem here, and if so, couldn't we solve it in some other
> manner?

Imagine you have a file under supervision in auto-revert-mode. If the
watch is broken or removed (by a *-rm-watch call), autorevert could
still work due to the polling mechanism in autorevert.el.

Best regards, Michael.

Re: New file notification event `stopped'

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 10 Oct 2015 13:56:43 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Nobody did reply.
> >
> > I did.  Or I thought I did, but now I cannot find my response in the
> > archives.  Maybe it's my imagination, or maybe it has something to do
> > with the recent snafu in GNU mailman archives.
> 
> At least I haven't received an email from you on this topic. Usually,
> you Cc the sender of a message.

Yes.  I guess I was dreaming.  It happens.

> > In addition, I don't know how to implement this in w32notify.c, at
> > least not easily.  As I said, when the watched directory is deleted,
> > the thread that watches exits with an error status, that's all.
> 
> But isn't there at least the `removed' event? Or is it just for files of
> the watched directory, and not the directory itself?

The latter, AFAIR.

> > What problem should this 'stopped' event solve?  Do we really have a
> > real-life problem here, and if so, couldn't we solve it in some other
> > manner?
> 
> Imagine you have a file under supervision in auto-revert-mode. If the
> watch is broken or removed (by a *-rm-watch call), autorevert could
> still work due to the polling mechanism in autorevert.el.

Shouldn't it be possible to test the validity from time to time?

Re: New file notification event `stopped'

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> Imagine you have a file under supervision in auto-revert-mode. If the
>> watch is broken or removed (by a *-rm-watch call), autorevert could
>> still work due to the polling mechanism in autorevert.el.
>
> Shouldn't it be possible to test the validity from time to time?

autorevert.el, like all other packages using file notifications, could
install timers for watched files or directories, checking whether there
are still valid watches. Many timers, and all users of file notification
need to do the same. It would be a polling behaviour.

The charm of the `stopped' event would be, that all of this is not
necessary. Just an event to be handled in the package's file
notification handler, that's it.

Best regards, Michael.

Re: New file notification event `stopped'

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sat, 10 Oct 2015 15:35:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Imagine you have a file under supervision in auto-revert-mode. If the
> >> watch is broken or removed (by a *-rm-watch call), autorevert could
> >> still work due to the polling mechanism in autorevert.el.
> >
> > Shouldn't it be possible to test the validity from time to time?
> 
> autorevert.el, like all other packages using file notifications, could
> install timers for watched files or directories, checking whether there
> are still valid watches. Many timers, and all users of file notification
> need to do the same. It would be a polling behaviour.

No, I meant the single timer we already have there.

> The charm of the `stopped' event would be, that all of this is not
> necessary. Just an event to be handled in the package's file
> notification handler, that's it.

autorevert.el doesn't scale well anyway.  E.g., global-autorevert-mode
can potentially consume a lot of system resources (handles etc.) that
are at premium, and we already had a few bug reports for that.

But that's another issue.

Re: New file notification event `stopped'

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> autorevert.el, like all other packages using file notifications, could
>> install timers for watched files or directories, checking whether there
>> are still valid watches. Many timers, and all users of file notification
>> need to do the same. It would be a polling behaviour.
>
> No, I meant the single timer we already have there.

That could be a solution for autorevert.el. But it doesn't work for any
other package using file notifications. They would need to poll as said.

Best regards, Michael.

Re: New file notification event `stopped'

[Michael Albinus]

Hi,

finally, I've pushed an implementation for the `stopped' event,
including extension of file-notify-tests.el. I hope this fixes also the
problem on hydra.

@Eli, could you pls check that it works also for w32notify? 

Best regards, Michael.

Re: New file notification event `stopped'

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: emacs-devel@gnu.org
> Date: Sun, 25 Oct 2015 14:21:55 +0100
> 
> finally, I've pushed an implementation for the `stopped' event,
> including extension of file-notify-tests.el. I hope this fixes also the
> problem on hydra.

Thanks.

> @Eli, could you pls check that it works also for w32notify? 

The test passes.  Do you want me to check something else?

Re: New file notification event `stopped'

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

>> @Eli, could you pls check that it works also for w32notify? 
>
> The test passes.  Do you want me to check something else?

Thanks for the test! No, I don't need more for that. The test passes
also on hydra, again.

Best regards, Michael.