From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] Date: Mon, 24 Jan 2022 08:26:26 +0800 Message-ID: <87y236ou6l.fsf@yahoo.com> 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> <87a6fntgfh.fsf@yahoo.com> <25069.23134.887206.241281@chiark.greenend.org.uk> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1931"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: Eli Zaretskii , 53432@debbugs.gnu.org To: Ian Jackson Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 24 01:27:09 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 1nBnCP-0000GG-Fb for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jan 2022 01:27:09 +0100 Original-Received: from localhost ([::1]:59470 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBnCO-0004Z2-Ip for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jan 2022 19:27:08 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:37098) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBnCI-0004Yu-Gs for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 19:27:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48647) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBnCI-0006hh-7S for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 19:27:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBnCI-00010H-1t for bug-gnu-emacs@gnu.org; Sun, 23 Jan 2022 19:27:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jan 2022 00:27: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.16429840043831 (code B ref 53432); Mon, 24 Jan 2022 00:27:02 +0000 Original-Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 00:26:44 +0000 Original-Received: from localhost ([127.0.0.1]:41550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBnC0-0000zi-3C for submit@debbugs.gnu.org; Sun, 23 Jan 2022 19:26:44 -0500 Original-Received: from sonic317-33.consmr.mail.ne1.yahoo.com ([66.163.184.44]:37032) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBnBx-0000zV-FV for 53432@debbugs.gnu.org; Sun, 23 Jan 2022 19:26:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642983995; bh=4+ifO0Ny7UA2NoDEkwpX1Ws19ncInQSYl2P/A1kJngc=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=VBkztb/J7Ewv8qe/BmwAMN0lhfIxbIA1B8y6Z6niFaEPcbXj80GGfjML8Mq4qFe2iiZtm1NFklMD7/CtS0C6b9nnPztOc0fBVQrnzNLJslFesYrKIC4E9BtSYvIfWvVOpj/kpNKd6HpKNdj05uHA83yZYBCtofDyhqow436PBMAxaWxpI3nbSypNpahLbXg/PGaaiCgLC+nCfZyZGY9If6jBEZmcjbmN3H1Q+LgzgGTzQRhO0V9NlzFF4r6g4Ya8IKBvzQuO+T7dwywxJUTFLbstmZfL0pRotBsq/HhSgsid6WXtGHr1PWXuGssWmkzrqi7JPvEqD4LfixKS11kyKg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642983995; bh=I38UI0ZJc6OWNfcYzKuCfZHUcfnEe6rZbC5clv8vjVy=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=oVaFW8yEenr1jDkRHQq3BCpVb1ai5h/d0eQFtif2b79fz2b1TkCzAFYHPKvLT3mRu33086J24WRZeqAd9z+qGrCdRPKdRa3lSlGeC3bkb5bz4BZly5DwG2FUyu2aB0grnu3WuYsEcXT2quHn58uoJxT13QkUnN+kZTYBMaQCh1vb6MBP3Ae8bWVkhgmWzHqTpBA4m/fTdWo2K12XIyDS90neJk6HtQru6MKbeUmGY7wC8rY1RpexXK3cS+t30obywJYA9OAZGejS0VkLk5s3VX/djJirZxr3T4y9qd7XUSc3RCQMwb4k1ASJwVBNYj1jP7z57aDZmw7eyLFeFc+/lg== X-YMail-OSG: mDBJmfIVM1naZJbb_y3Z5YVow6GeA2a6PNip64pwrCUwfnXYOt1CKEBjb4aOab2 GN6Ohgqawfs4QYLE2jaDctycJJ8aKMVi1oXr09ocyZq9_DOQ_.j6Ie2S.LUIcONOUaGJUqIuSqTB Vb_cGU_l8yZilM_dgQ1WCRNYibzfFvalFbF2QGmcVoTIXxHWZ87fPfX5xSCmYwYGifYvk5pl.lgn txVIv74AEO9F2ZejV7jsiWx1ji_N3jpYvbc6pB__bXCNGCBc_Yj1mCoLkMoXBHoSjVmjCYCOA_Gu QQ1roLY5A8bekCrfuQt2U4gRTZmL5aPNhOCtw2MUGz4TM_5WaFFwE_kNN5WT5n7fETQt.NA2rqa_ cbvZTy3nWYue3O5Fg8wGkrmfWrHU4u8a7fwmWvjqEcL7zm1uFfD1qZggzveBqnBivHocBL87soDF 3aJqJXsazEz9vcJJWGKiMwp2BiXKAAISO4QbRWzVzWVkqI6fHA0b0sGmVxSIu4bbVLBU_j2ebLzT 7T.J6TdgXus43lnjPl6qEATTBoAAAvVqQd8O1J94xM3xKqvvGfmdSyHUgEanWtrI1Ch38ar7lUPE jXUdzM1AcCrr3ioHj_S4OoMARlgSVphpRzcFazKVRKN0WGoB87R9zZWhZW7kiGZElkQ1Dm2eG9Hw Cp3bR5POy27lZv0M_uqXjkw77EEkIdq6_7IfDwYWGEvj.qIr2camMTUzFYIR0vyZzDxWyMlyi66D QD.LZEWAkkua_64fsHfe4JqWetwlbbrj.EuSfZpIMSf9VMJEW8Cuu7DOnWM6CRtkJ7.suTZ3G9Og 2Q.HGiqVAJil3qQ.GUguum0ffoO.2Hmo5h8XnMwwta X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Jan 2022 00:26:35 +0000 Original-Received: by kubenode504.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID cabb1ca561312f7441a041af1965e5ab; Mon, 24 Jan 2022 00:26:30 +0000 (UTC) In-Reply-To: <25069.23134.887206.241281@chiark.greenend.org.uk> (Ian Jackson's message of "Sun, 23 Jan 2022 13:38:38 +0000") X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:224980 Archived-At: Ian Jackson writes: > I suggest the following approach for stable branches: > > 1. Have the inotify code drop notifications if kbd_on_hold_p(). > This will mean that keystrokes will never be lost. It's too late to do anything of this sort on the release branch. > 2. At least double the size of the keyboard buffer from 4k to 8k. > I think this is necessary because in a stable branch we don't want > to make anyone's experience worse. Doing (1) will cause emacs to > start to lose file notifications when the buffer is half full, > rather than full. Doubling the buffer (at trivial memory cost) is > an easy way to fix this. Why is that? I'm not convinced that's necessary, since you're the only person to complain so far, and you needed to abuse the feature in order to get keys to be dropped. > 3. Consider a significantly larger bump to the keyboard buffer to > further reduce the incidence of this unreliability. It's a single > static buffer; we could easily change it from 4k to 40k (say) with > negligible cost. 40k is unacceptable. > If desired, the increased keyboard buffer size could be made conditional on > inotify support so that systems which don't use the keyboard buffer > for file notifications don't pay a price. We have many other file notification systems, essentially one for each platform we support. The one that people actually build Emacs with is in gfilenotify.c, and you can't get it to experience such problems since it will silently drop file notifications once its own internal buffer fills up. GLib does not tell you when that happens, because it happens rarely enough to be worth taking into account. > For master, I still think we need to make global-auto-revert-mode > reliable. We don't want to stop using file notifications for it > (where they are available), because we don't want emacs to be polling > - that is poor for battery life on laptops. Someone has to demonstrate that running `stat' every five seconds actually results in the visible decrease of battery life before we take that into account. > IF we did this then the inotify code could use the same mechanism to > handle the case where it dropped events due to the kbd_on_hold_p, and > everything would work correctly. Complicated buffer management in the > inotify code wouldn't be needed. We don't want to drop inotify events when keyboard input is paused, we only want to drop them when `kbd_buffer_nr_stored' is equal to KBD_BUFFER_SIZE. > We would still probably want to have a significantly larger keyboard > buffer, at leat when inotify is enabled. The keyboard buffer is read very rapidly in most cases, so that shouldn't be necessary at all. > This is because we can reasonably expect a much higher rate of file > notifications than keyboard events. Even if we have made emacs > reliable when the buffer fills up, we still don't *want* the buffer to > fill up because the non-file-notification based auto revert is a lot > less efficient, especially in a large emacs visiting many files: it > will often be the case that only a handful of files have changed, > perhaps very many times. That sounds like premature optimization to me. Between Emacs 25 and 26, file notifications were disabled for global-auto-revert-mode, and I don't think anyone complained very loudly. > The inotify code has its own buffer in inotify_callback. On each > pass, it calls FIONREAD and passes the return value to SAFE_ALLOCA. > I think this is quite pathological. SAFE_ALLOCA does not usually allocate anything on the heap, so its impact is negligible. > I'm not familiar with glib. Presuambly glib either exposes something > with the semantics of IN_Q_OVERFLOW, or internally converts that to a > notification to every watcher. Otherwise programs using glib's API > would have to poll, which seems unlikely - I think that the glib > authors will be well aware of the desire to avoid polling for battery > life reasons. It does not. It happens rarely enough that the GLib target audience doesn't care about when file notifications are actually dropped. > In emacs 27 and 28 it was necessary to be more aggressive to create a > situation where the bug would reproduce. This is in the nature of > this kind of bug. Why is that so?