unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattiase@acm.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: emacs-devel@gnu.org
Subject: Re: master e9e807e: Don't remove notify descriptor that is already gone
Date: Tue, 16 Apr 2019 15:31:08 +0200	[thread overview]
Message-ID: <BC9D5F1D-A8AC-4D45-96C7-24627DDB51C3@acm.org> (raw)
In-Reply-To: <871s2277mv.fsf@gmx.de>

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

16 apr. 2019 kl. 09.04 skrev Michael Albinus <michael.albinus@gmx.de>:

> I haven't tested thoroughly yet, but wouldn't it suffice if in
> auto-revert-notify-rm-watch there is just the test
> 
> (when (file-notify-valid-p auto-revert-notify-watch-descriptor)
> 
> instead of
> 
> (when auto-revert-notify-watch-descriptor

Thanks for reading my change. It is a fair question!

First of all, the descriptor wouldn't then be removed from `auto-revert-notify-watch-descriptor-hash-list' since that part is also guarded by the condition, but that's just a matter of rearranging code.

(Not only is `auto-revert-notify-watch-descriptor-hash-list' a mouthful, it is a bit misleading. It maps descriptors to lists of buffers. How about `auto-revert--buffers-by-watch-descriptor'?)

I'm not necessarily enamoured with `file-notify-valid-p'. It just tells whether there is, right now, a descriptor that looks like the argument, in use by someone, somewhere. These descriptors are reused, making the predicate dangerous to rely on, or requires brittle code that just knows that no reuse has occurred.

Slightly more robust would be to stop reusing descriptors: either made mutable, so that they can be invalidated, or made unique by using a counter. However, the basic design is still somewhat dubious: it tells us whether the descriptor is valid, but that just raises the question: why do we even have to ask? Correct code should understand its own invariants.

Now that you `mentioned auto-revert-notify-rm-watch', does it strike you as odd the way it does

    (maphash
     (lambda (key value)
       (when (equal key some-key)
         do-something))
     some-hashtable)

instead of using the hash table directly? Suggested patch to fix this attached.

(For that matter, the documentation doesn't say what mutation is permitted inside `maphash'. I can guess from the source.)

By the way, why don't we give each buffer in auto-revert-mode a unique descriptor, so that the table just maps descriptors to buffers, instead of to lists of buffers? It would simplify the code in many places, and it cannot be that common to have multiple buffers for the same file that it warrants the descriptor-sharing optimisation.

[-- Attachment #2: 0001-autorevert.el-auto-revert-notify-rm-watch-Simplify.patch --]
[-- Type: application/octet-stream, Size: 2009 bytes --]

From 00733fac960526e25e5f7e5d68be48d042d28315 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mattias=20Engdeg=C3=A5rd?= <mattiase@acm.org>
Date: Tue, 16 Apr 2019 15:13:57 +0200
Subject: [PATCH] * autorevert.el (auto-revert-notify-rm-watch): Simplify.

---
 lisp/autorevert.el | 24 +++++++++++-------------
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/lisp/autorevert.el b/lisp/autorevert.el
index 1dc2f0eafd..cf9dc53f85 100644
--- a/lisp/autorevert.el
+++ b/lisp/autorevert.el
@@ -501,19 +501,17 @@ will use an up-to-date value of `auto-revert-interval'"
   "Disable file notification for current buffer's associated file.
 If REMOVE-DESCRIPTOR is non-nil, remove the corresponding notification
 descriptor; otherwise assume that it has already been removed."
-  (when auto-revert-notify-watch-descriptor
-    (maphash
-     (lambda (key value)
-       (when (equal key auto-revert-notify-watch-descriptor)
-	 (setq value (delete (current-buffer) value))
-	 (if value
-	     (puthash key value auto-revert-notify-watch-descriptor-hash-list)
-	   (remhash key auto-revert-notify-watch-descriptor-hash-list)
-           (when remove-descriptor
-	     (ignore-errors
-	       (file-notify-rm-watch auto-revert-notify-watch-descriptor))))))
-     auto-revert-notify-watch-descriptor-hash-list)
-    (remove-hook 'kill-buffer-hook #'auto-revert-notify-rm-watch-callback t))
+  (let ((desc auto-revert-notify-watch-descriptor)
+        (table auto-revert-notify-watch-descriptor-hash-list))
+    (when desc
+      (let ((buffers (delq (current-buffer) (gethash desc table))))
+        (if buffers
+            (puthash desc buffers table)
+          (remhash desc table)))
+      (when remove-descriptor
+	(ignore-errors
+	  (file-notify-rm-watch desc)))
+      (remove-hook 'kill-buffer-hook #'auto-revert-notify-rm-watch-callback t)))
   (setq auto-revert-notify-watch-descriptor nil
 	auto-revert-notify-modified-p nil))
 
-- 
2.20.1 (Apple Git-117)


  reply	other threads:[~2019-04-16 13:31 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20190415083338.9906.18508@vcs0.savannah.gnu.org>
     [not found] ` <20190415083339.64FE620536@vcs0.savannah.gnu.org>
2019-04-16  7:04   ` master e9e807e: Don't remove notify descriptor that is already gone Michael Albinus
2019-04-16 13:31     ` Mattias Engdegård [this message]
2019-04-19 14:56       ` Michael Albinus
2019-04-20 10:20         ` Mattias Engdegård
2019-04-22  8:37           ` Michael Albinus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BC9D5F1D-A8AC-4D45-96C7-24627DDB51C3@acm.org \
    --to=mattiase@acm.org \
    --cc=emacs-devel@gnu.org \
    --cc=michael.albinus@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).