[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
New file notification event `stopped'
From: |
Michael Albinus |
Subject: |
New file notification event `stopped' |
Date: |
Sun, 27 Sep 2015 11:08:51 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- New file notification event `stopped',
Michael Albinus <=