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: Sun, 23 Jan 2022 09:00:02 +0800 Message-ID: <87a6fntgfh.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> 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="16945"; 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 Sun Jan 23 02:01:21 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 1nBRFx-0004GP-CP for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 23 Jan 2022 02:01:21 +0100 Original-Received: from localhost ([::1]:56476 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nBRFw-00071Y-9p for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 Jan 2022 20:01:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:38754) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nBRFh-0006zU-Qs for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 20:01:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45346) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nBRFe-0001eV-Lf for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 20:01:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nBRFe-0004EJ-Lm for bug-gnu-emacs@gnu.org; Sat, 22 Jan 2022 20:01: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: Sun, 23 Jan 2022 01:01: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.164289962216163 (code B ref 53432); Sun, 23 Jan 2022 01:01:02 +0000 Original-Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 01:00:22 +0000 Original-Received: from localhost ([127.0.0.1]:38239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBREz-0004Cd-JB for submit@debbugs.gnu.org; Sat, 22 Jan 2022 20:00:21 -0500 Original-Received: from sonic309-22.consmr.mail.ne1.yahoo.com ([66.163.184.148]:46671) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nBREx-0004CP-Gs for 53432@debbugs.gnu.org; Sat, 22 Jan 2022 20:00:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642899613; bh=sVSOkxhKQ1VKb0NQlIGx5kM8qJ0dosuXT3ZWunFPils=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=oGXlOgAK4vDfUfK1CTwnF3BWnYXjWQCY9S/HJUtn7USohTD5whMHCMDdO89Lq/PDeXBz+RqlNtpAutEroFkJqhFbsDRCKQ4Mso+Fgin3Azft2/c2QvOmEjQCuCWMC9t1D9EXUTkdSP4HKst3v6pf75cHSyhSgyXVd8K807ivil8BLtjVdZ1b5bVyxrqxGrvCJ4eZ5VL4rKKVJ//xLF+Olc9/tQUW0nX0H/dqj64obpOloYbCcfSIpUOJp8tgFOLScPijO0wZIGsV2ClmhVqLdurGQaRvJL69mA3VImoRCN6taXK8mtwLHMB/Bu+E1oaiyb+8VE+HHIKLxpJEEpFdsA== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642899613; bh=eJq2MpgA76IWKZyPeQt1yQCYQjzeWofuYXegom6CCVL=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=H2eGgbLUx0hB38Z9BQWLZm1r4zxWTWYtCaTShXrLd+F+dLLYwj1LdgwKKM99In0hAI6eXLFktamvdteKNYH4XsSdixUG8Dvc1uOGfoDd0b8SnNHdFlrEwSi37ORoLTjzVIM9zLcHhS3l9Xu1gGE2i4VLI7TrizuRibMBQM9UIAyx8XkP203gBhB5V2LYl7GgJWOr+yYxD2F1Iniahu8MvAZ/ZsNili6TqPYVmeA4WzM6id1mJejnLgxd6SgQDwpjMmJcp4sSWN4eJ2lsd2E4vvrMKipWGBmYIN3lCvNf5717LS3vY2QHqC5DPBXYxdpd/icKPLqHtcp+lNDyfLXhMg== X-YMail-OSG: HFqZmHMVM1nqyZkwN2.UeVIEtRMkhFbUERT2GqmchshNxQ197StjpKjwyBl2KNh 4GHVm3_feBKsoZw7Ft7HWWorx_V3_exW_DprYZyWyj7nVkXMbhGq1MfSA3DGCAfa7B_DxR2W5uOo j848T8dX586_hEOQj5lVIxJWVSWAIUQ4n.RVdKyLGaK6kgTz7dIoTDwmyOHynvZqpLeCLjAvz1DE FVnHIPDSy22Ben_yI0hdIMaNssePl1qBdmvL2GleGITjpyBb3O91z9260NYuhWmU2HH86o2frXj7 ABOROV2h.y4QjXd69mMnOfPzTbzHV09_3Ve53yIJlpkfU6HdlJNxYUdEavXMHIHc0iPGKoOGls.E 8PFYrffQz1lkR7gaJQFMICn2WO1tba1v_atXuWXPwpTEBkwcHQfks9BMmtMD59KCLBZ5MgOyakBO XLHngPcQvHayZPH1rhk2YFqVnDmOjh0hP923qXE6ZZLMNLaY2d7hLAmOxLsT2gT9QA2yzmTcdsyR aAvWVqIaCq7Lb9gWY6XiYmuFXKm.IH0_o5WEXVSPTFkOG5GQgoHDny7TpEbt3kapvbnOwQGQn4V4 fCTI3MRZP5w.7nQcEgmmRwbi9m1PtX81wu1eR9vV_VXeoYatEn.BgZH60I_PI09l8USwCTVPriw. UDK7rfUHgdmkVL5uC6gveiLtYHOow086ErTF0MsCaf9rbRpx44GUQxowOhhljwLu3iQMtLyI4agL aSituRkt9rZzNaw8qyadwkvZHJrntT_fBI19faBTq4GnkW9Cs9ll6DFm7WVn8fQl8qqiG092gLZ_ N39OQWRKLYQtTlzDQ51P6UfBwnGq_cTUb4VDWuPGeW X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.ne1.yahoo.com with HTTP; Sun, 23 Jan 2022 01:00:13 +0000 Original-Received: by kubenode508.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 87bc7d1c6bacfbbcd6684ffc22f6cc33; Sun, 23 Jan 2022 01:00:06 +0000 (UTC) In-Reply-To: <25068.23625.512978.147194@chiark.greenend.org.uk> (Ian Jackson's message of "Sat, 22 Jan 2022 19:34:33 +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:224873 Archived-At: Ian Jackson writes: > I'm not sure what your underlying objection is to this, so I will > guess: I think you are concerned at the performance implications of > allocating each time we handle inotify events. But my proposed code > does not allocate each time. It only (re)allocates when it needs a > bigger buffer than it already has. The underlying objection is that it's IMHO wrong to allocate anything on the heap to cater to "abuse" of a feature, in this case inotify. > Wouldn't that lead to file notifications getting lost ? I think that > might result in buffers not being reverted, even though the user has > global-auto-revert-mode enabled. As I say that would be a problem, > because it can end up with the user editing the wrong version of a > file. I don't think it is OK. It can't end up with the user unknowingly editing the wrong version of a file, because Emacs will ask him: foo.h changed on disk; really edit the buffer? (y, n, r or C-h) When he first tries to edit the file again (the way this works is not file notifications, but instead comparing stat data.) There are also builds without file notifications, which are used on many systems. > If it is OK for file notifications to get lost, because the need for a > buffer revert will be picked up another way somehow, then your > suggestion makes perfect sense to me. But in that case, I don't > understand why this code doesn't use a buffer of fixed size (or, at > least, limited size). Which code? The keyboard buffer is the "buffer of fixed size" in the inotify code. > Or to put it another way, the current code does a hair-raising thing > for which the only explanation I could think of was that it is aiming > never to lose notifications; and if there's a comment somewhere saying > that the whole inotify system is best-effort, and it's OK for it to > drop things when stressed, I have missed it. All file notification systems are "best effort". At the very least, dropping events when the keyboard buffer is full would make the behavior consistent with GLib file notifications, which drops notifications whenever its own internal buffer fills up. > If it is OK for it to be best-effort, then I think this needs to be in > the documentation for inotify-add-watch. Currently it says > > The watch will look for ASPECT events and > invoke CALLBACK when an event occurs. > > and there's nothing saying "it might not happen, so you must arrangee > that this is not the sole way you are looking for changes". I think > that'd be an API which would invite programmers to write and ship lost > event bugs, especially since usually it would work just fine. It's acceptable for there to be some lossage when confronted by (in your own words) abuse of a feature. That is taken for granted, whether or not it is documented. Thanks.