From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Newsgroups: gmane.emacs.bugs Subject: bug#35418: [PATCH] Don't poll auto-revert files that use notification Date: Mon, 29 Apr 2019 13:54:48 +0200 Message-ID: <093C7A57-E3EA-446D-B283-07328850094A@acm.org> References: <83sgu71b91.fsf@gnu.org> <74CB5185-5DA1-4786-BD9C-9EEB3D43B3C1@acm.org> <83o94uz9h2.fsf@gnu.org> <875zqzssql.fsf@gmx.de> <87bm0pqnvl.fsf@gmx.de> Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="151887"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 35418@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Apr 29 13:55:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hL4sI-000dLo-Tr for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 13:55:11 +0200 Original-Received: from localhost ([127.0.0.1]:56260 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hL4sH-0007eb-PR for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Apr 2019 07:55:09 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38116) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hL4sB-0007eH-4X for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 07:55:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hL4s9-0006m3-Va for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 07:55:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53245) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hL4s9-0006lr-Sd for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 07:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hL4s9-0000HG-Mn for bug-gnu-emacs@gnu.org; Mon, 29 Apr 2019 07:55:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Apr 2019 11:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 35418 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 35418-submit@debbugs.gnu.org id=B35418.15565388951050 (code B ref 35418); Mon, 29 Apr 2019 11:55:01 +0000 Original-Received: (at 35418) by debbugs.gnu.org; 29 Apr 2019 11:54:55 +0000 Original-Received: from localhost ([127.0.0.1]:38556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hL4s2-0000Gs-O2 for submit@debbugs.gnu.org; Mon, 29 Apr 2019 07:54:55 -0400 Original-Received: from mail158c50.megamailservers.eu ([91.136.10.168]:35404 helo=mail51c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hL4s0-0000Gj-8K for 35418@debbugs.gnu.org; Mon, 29 Apr 2019 07:54:53 -0400 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1556538890; bh=gD1tusVh40ZNP3JXWqPzITjHaN/obO76hTNAFyfOMKs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Y8cShCsvhUB5i0pYzPQT4y4dBTo79LJwhwJYGCpQm/sQG102DsCNZFtwE9GcDJ9ld yNhyHPPFGqw+hwLdJZFm5nUUNGFOy+R0Bcx63RMnKRy3epJHOetVT+9eqK/cqcPSBs a4EvGp/G0ymyJPxzKW5gjzFAXGVA6T5efnmhJIuE= Feedback-ID: mattiase@acm.or Original-Received: from [192.168.1.64] (c-e636e253.032-75-73746f71.bbcust.telenor.se [83.226.54.230]) (authenticated bits=0) by mail51c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id x3TBsm9O000348; Mon, 29 Apr 2019 11:54:50 +0000 In-Reply-To: <87bm0pqnvl.fsf@gmx.de> X-Mailer: Apple Mail (2.3445.104.8) X-CTCH-RefID: str=0001.0A0B0213.5CC6E60A.003B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CSC: 0 X-CHA: v=2.3 cv=NqD/jfVJ c=1 sm=1 tr=0 a=M+GU/qJco4WXjv8D6jB2IA==:117 a=M+GU/qJco4WXjv8D6jB2IA==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=kj9zAlcOel0A:10 a=0RxXZDt1o24jnOP26QcA:9 a=hH4KKwJBM4O-6qDZ:21 a=RwYATyWX6-ytp6K0:21 a=CjuIK1q_8ugA:10 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:158422 Archived-At: 29 apr. 2019 kl. 09.19 skrev Michael Albinus : >=20 > By design, in filenotify.el, we want see only events which are related > to the file *name*. If you want to be notified for both buffers, you > need to watch both file (names). Well yes, but you want a change to the file to be reported for both = buffers, even if they watch different names, right? Otherwise, it wouldn't make sense at all. If someone is watching a file, = surely it is because changes to the contents of that file are of = interest? Why would the name employed to carry out the changes matter? I'm quite sure there is a simple misunderstanding here; probably my = fault. And again, I don't think it matters much in practice since users = are unlikely to have buffers for different hard links to the same file. = Let's not waste too much time on this. >> However, with the kqueue back-end, file-notify watches do trigger for >> both, as expected. >=20 > Hmm, this is inconsistent. Worth a buig report? Not really, because (a) multiple hard links are rare, (b) even more rare = in Emacs, and (c) inotify isn't used that way by auto-revert (the = directory is watched, not the files). > It was a design decision, that filenotify.el implements directory > watching. Since kqueue does not support this, it must be emulated, = somehow. Well, auto-revert only uses filenotify.el for watching changes to files = (that is, the data corresponding to the names). How filenotify does that = isn't very important. I suppose watching directories when possible has = the advantages: + fewer (kernel-level) descriptors used if there are multiple files of = interest in the same directory + notification about re-created previously removed files with at least one disadvantage: - changes to files not of interest have to be considered and rejected, = spending more CPU and power. This can be non-trivial; consider looking = at a single non-changing file in a very busy directory with files being = added and removed all the time. For kqueue and w32notify (and FSEvent) there isn't much choice. >> What other reasons are you thinking about? >=20 > The reasons you have already quoted somewhere else: sometimes, file > notification is not applicable; there are not enough descriptors left; = a > file might have been deleted; a file notification process has been > killed silently; you name it ... Thank you. Most of those cases should not cause any trouble -- except = unreliable file notification processes, but since = `auto-revert-remote-files' defaults to nil, it didn't look like a = serious problem.