From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] Date: Sat, 22 Jan 2022 21:48:21 +0200 Message-ID: <8335lfmu0q.fsf@gnu.org> References: <25067.17249.604070.872185@chiark.greenend.org.uk> <838rv8nua8.fsf@gnu.org> <87r190wqo1.fsf@yahoo.com> <25068.23625.512978.147194@chiark.greenend.org.uk> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9619"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 53432@debbugs.gnu.org To: Ian Jackson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 22 20:51:07 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nBMPi-0002Fb-47 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jan 2022 20:51:06 +0100 Original-Received: from localhost ([::1]:60976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBMPg-0005Tm-SP for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jan 2022 14:51:04 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:48592) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBMOh-0005TJ-4w for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:50:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45081) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBMOg-0000Jr-Ku for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:50:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBMOg-0004rj-Fs for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 14:50:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 Jan 2022 19:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53432 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 53432-submit@debbugs.gnu.org id=B53432.164288094618631 (code B ref 53432); Sat, 22 Jan 2022 19:50:02 +0000 Original-Received: (at 53432) by debbugs.gnu.org; 22 Jan 2022 19:49:06 +0000 Original-Received: from localhost ([127.0.0.1]:37984 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBMNm-0004qQ-1j for submit@debbugs.gnu.org; Sat, 22 Jan 2022 14:49:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBMNl-0004pw-1A for 53432@debbugs.gnu.org; Sat, 22 Jan 2022 14:49:05 -0500 Original-Received: from [2001:470:142:3::e] (port=57550 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBMNU-00009g-Th; Sat, 22 Jan 2022 14:48:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RFRxOqdR/65ZkIK9cGIMlFKVmxqSAsq/atGJLZ4YFmE=; b=ZDFob/Cd0pao V2ovq1jK2TWcsCj4XuhO1zm8Z2LFZhigbSgfP4CP/AUDQzSwAXwi4kqPSEqu5tZdlVMQKJp3ddpUa +bIr2ukIuHrItHtg9y1cdX7SPxAbJsowsWTysLyeeccbMYXIXJFQmDqdttDye8Q/GP0nn9U9C6r5u RsRhD+EbHqLymdfyiACgTFseepfRY/R23KV9Tuvpzqy0p5HaF95fXlR+MomwxftKPSHjMSTgEMoy8 INPHTNf7XxsU6CgugR1PL+zOFjJlPjIwdS6OemusOgR/schxFGr+bcL8aklHWSVPLISVjMQdl4IVh vdAlNf4QZgKAbKP9szbF4Q==; Original-Received: from [87.69.77.57] (port=1921 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBMNL-0008N9-Q3; Sat, 22 Jan 2022 14:48:44 -0500 In-Reply-To: <25068.23625.512978.147194@chiark.greenend.org.uk> (message from Ian Jackson on Sat, 22 Jan 2022 19:34:33 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:224862 Archived-At: > From: Ian Jackson > Date: Sat, 22 Jan 2022 19:34:33 +0000 > Cc: 53432@debbugs.gnu.org > > Eli Zaretskii writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy"): > > Thanks. I doubt that we want to complicate our input handling this > > way on behalf of "abusing" inotify. File notifications are known not > > to be scalable enough to support global-auto-revert-mode well. > > The problem is that keystrokes (and file notifications) get lost. I > don't think we should be shipping code that can do that. Even if it > only does it if you are working on a program whose build system writes > a lot of files, and/or have a slow computer, and/or are unlucky. Note > that magit turns on global-auto-revert-mode so this is a very common > configuration. Loss of file updates is also a real problem, becuase > it can lead to the user editing an old version of a file. Which is why we recommend turning off file-notifications when you turn on global-auto-revert-mode. > The fact that I have to "abuse" things to demonstrate the race, does > not mean that it's not a real bug. That's in the nature of race bugs. What race is that? This processing is going on in a single thread, so how can there be any races? > > The best thing to do, IMO, would be to simply not store any > > FILE_NOTIFY_EVENTS if the keyboard buffer is full, which shouldn't > > affect normal use of file notifications, and would result in less change > > to the keyboard code. > > Wouldn't that lead to file notifications getting lost ? Yes, but inotify (and other similar features on other OSes) doesn't guarantee that all the events be delivered when there are many of them. Which is one more reason not to use file notifications to watch too many files/directories. This stuff isn't scalable enough. > Eli: > > In any case, installing this on the emacs-28 branch is out of the > > question: it's too late for that. We may install some variant of this > > on master, after discussing how best to handle this. Po Lu's > > suggestion to stop processing inotify events sounds better to me. > > I was advised by a friend that I ought to send patches against > the emacs-28 branch, so I did that. Indeed, CONTRIBUTING says > > If you are fixing a bug that exists in the current release, you should > generally commit it to the release branch; It also says, right after that However, when the release branch is for Emacs version NN.2 and later, or when it is for Emacs version NN.1 that is in the very last stages of its pretest, that branch is considered to be in a feature freeze: only bug fixes that are "safe" or are fixing major problems should go to the release branch, the rest should be committed to the master branch. This is so to avoid destabilizing the next Emacs release. If you are unsure whether your bug fix is "safe" enough for the release branch, ask on the emacs-devel mailing list. > > > I hope the commit messages are in the expected format. I think I > > > probably have GNU copyright paperwork on file already, perhaps under a > > > different email address. > > > > I don't see your name or email address on file, so maybe they are both > > different? > > My name hasn't changed. But I'm happy to do the paperwork (even if it > would be "again"). If it did happen, it will have been a long long > time ago. Sorry, I don't see your name there. I just rechecked.