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

Mattias Engdegård <mattiase@acm.org> writes:

Hi Mattias,

>> 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.

Yes.

> (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'?)

No objection.

> 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.

In theory you are right. But I fear there could be situations where such
assumptions do ne keep. A double-check is OK.

> 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.

I'm still not convinced that we need REMOVE-DESCRIPTOR. We shall always
remove the descriptor, and assure, that no superfluous events are raised.

> 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.

Well, the descriptor is the one we get from filenotify. I don't believe
we shall do double housekeeping. Sounds to me error-prone.

Best regards, Michael.



  reply	other threads:[~2019-04-19 14:56 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
2019-04-19 14:56       ` Michael Albinus [this message]
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=87wojqhwlk.fsf@gmx.de \
    --to=michael.albinus@gmx.de \
    --cc=emacs-devel@gnu.org \
    --cc=mattiase@acm.org \
    /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).