From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Michael Albinus 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 18:05:29 +0100 Message-ID: <87bl01rrmu.fsf@gmx.de> 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> <877daqtnkw.fsf@gmx.de> <25069.40682.688423.883151@chiark.greenend.org.uk> <87lez5ry92.fsf@gmx.de> <25070.51632.699234.228230@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31632"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: Po Lu , 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 18:16: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 1nC2wo-00080R-U5 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jan 2022 18:16:07 +0100 Original-Received: from localhost ([::1]:55280 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nC2wn-00037V-UA for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 24 Jan 2022 12:16:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52568) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nC2n5-0000sj-9Y for bug-gnu-emacs@gnu.org; Mon, 24 Jan 2022 12:06:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52638) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nC2n4-0005zf-HB for bug-gnu-emacs@gnu.org; Mon, 24 Jan 2022 12:06:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nC2n4-0003Mq-DZ for bug-gnu-emacs@gnu.org; Mon, 24 Jan 2022 12:06:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Albinus Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 24 Jan 2022 17:06: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.164304394112910 (code B ref 53432); Mon, 24 Jan 2022 17:06:02 +0000 Original-Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 17:05:41 +0000 Original-Received: from localhost ([127.0.0.1]:45541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nC2mi-0003M9-Kj for submit@debbugs.gnu.org; Mon, 24 Jan 2022 12:05:41 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:36099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nC2mg-0003Lq-Cv for 53432@debbugs.gnu.org; Mon, 24 Jan 2022 12:05:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643043930; bh=zkV9m3i4AOtzYGlhGqg/8VMfjEtsZMFuC8DpMoTUw/U=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=fIPbqSQSPQ9X0QdQaxybIIefjjMKcfoylu0VbqUefTawlKLAlNSUYSZgeKO3XWG4q 1ePC+wQSvALAdEdhl8XIeBQMAi1xhIjBfTc8APwnWVXC3/1l+KulLUxMQxi+aqh8Qq OoY3AD4lHL3pb8ee4Y2DUchVXj1v73byFEv/qsdk= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from gandalf.gmx.de ([79.140.118.216]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MOA3P-1mwpH91Fbl-00Ob8O; Mon, 24 Jan 2022 18:05:30 +0100 In-Reply-To: <25070.51632.699234.228230@chiark.greenend.org.uk> (Ian Jackson's message of "Mon, 24 Jan 2022 15:45:52 +0000") X-Provags-ID: V03:K1:YYxoExyuFFBbApdfMYHwCGGTQ11vG0lUOikMDpJlkxERbZ/+KlN CSneIDT46SQ54JnKQbKayXjPZZrGZ21E3gyHiD9u/iNQpNXZommJ+LR6BU3gCICK7mf0ysa +m/Kp0ilGbDVz2OnsZRC3CdYldklGp/ExajZoCfRSMyBp7eJEokPrSn1XTOpLysBpHpt+uP qLEOhGzm5/8TmHJUCY7NQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:7HDtihkci/U=:eic+Lv7Hlwn9VGVTYuvBCO 0JXTJlQbyO1DP6ENyqdVWa43500H070Lj6Dhl8aCmko9w9qugA7lGu1BK3+SomDS9br8Sgg1F ovCDXY2jd1qjz+eHdb0Gr4hiWu7hPIFHh2zqti5WCOIpTUMQOIs6fYQKqmn7Fj1K4gsIrwBRD jd1wjsX7rAxIoXYbCZsmDckGdhbtIiJCEEAVRwO7Ztwk9Mub+FjWE1zzS43l2ufPPYXlhGX0S djEhjDBOoyTjE4DWFFH9I0+7r5wF2Es1vDSjvJXeHNakHik5zV27wQSB42WPVCFWtIFa+BtBM eu9gMUbBU6ELGVR8Cll8tmPt2zzvxHaBiv0X16IVNTs/LVzdBIpNxLLoynCGYcn1mIZcqWQDk eJW6iop+z2AmvX/hkskfNx6egUBk5o287EADlKAKfxmdOidFIqiKs4Ymbv1kvy5EZlhQU1L78 6a6GvM8KPKETAsYxzbFI7EOPEkswyG5qwKueAa/OTeNlIRi2UdZn54t31GQdOjeO46MHjYw9p /VfnU+AeacOEWd/FnOuezPeF2uxhmWCvc9jLVpCuKxgYzuOyfPkabUJ1SAdQFqUQFe6yHLydc H46C2QhVe/Ubzp1GBmXufl2I4ATixyEG+Bux2sNEpffSLeRXVB+dgjjFXOMRw5nhDBlbks1p7 Bkc0AGTt3M3703i1b0hRyPDDv9R/Csn06Ml95uTWWnEqZyi9JsNK0TPnAdmjSTjRGPN/7IOOq pxOM4T311QpE7Lih2CBtNiXU/GEHA+YVeD0kiWw4mf8E63DY/uQpzykRhxtZvykqS9cc+Nt0 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:225078 Archived-At: Ian Jackson writes: Hi Ian, >> Yes. But if we divide the keyboard buffer (also good for mouse events >> and other events which do not harm) from the D-Bus and file notificatio= n >> events, such a check is needed at fewer places. > > I don't follow. > > Any buffer that we have can fill up. So each thing that generates > events needs to be able to handle the buffer (that it is writing to) > becomeing full; and to be able to handle the buffer becoming > no-longer-full, so that it can restart. > > So each event-generator has a "stop" hook and a "start" hook, each of > which has one call site, in the code that handles the buffer for that > event generator. The number of these calls is the same either way. > > The difference is just whether there are two buffers, which call > disjoint sets of start/stop hooks, or one buffer, which calls all the > start/stop hooks. My proposal was to keep the keyboard buffer as-it-is for key strokes and alike. No need to change anything. A new buffer for D-Bus and file notification events would need an additional handling for a burst of events. But as Eli has replied, this brings further problems. So I don't follow any longer this approach. >> The advantage of splitting into "keyboard" and "other things" buffers >> would be, that the keyboard buffer doesn't overrun, whatever burst of >> D-Bus or file notification events arrives. > > The two sets of code would seem very similar. It would probably be > sensible to actually use the very same code and data formats and > everything. The advantage is precisely that we can prioritise them > differently: the keyboard buffer could keep working, even while the > other buffer is full. In practice I don't think this is likely to be > particularly important since we don't usually expect emacs to be > overloaded in this way. And when it is, there is an argument that > processing events in order is likely to be better in the sense that it > is less confusing to the user. Again, two different buffers are out of discussion ... >> Yes. But I believe we don't need to handle lost events. If we have a >> mean to inform the upper libraries, filenotify.el and dbus.el, about >> this case, it would be sufficient. A simple check whether the event >> buffer is full. > > I think we are just having a semantic difference here. To my mind > "handling" lost events *consists of* notifying the next layer up that > "some events may have been lost". Eventually this informaton will get > to somewhere that can do something sensible with it. Yes, if we are speaking about the file notification backends, that's all. And that's what I meant (sometimes, you must forgive me if I use unprecise English). >> I don't believe that the native backends, like inotify.c, deserve too >> much intelligence. They shall do stupid event receiving and reporting, >> with a callback invoked in case of problems. This callback must be >> clever then. > > If the buffer overflowed, it is quite easy to discard now-superfluous > events at the lower layer (thus coalescing events into the single > "some may have been lost" callback). At higher levels the state > machine needed to do this becomes more complicated. Agreed. > I suggest introducing a version of kbd_buffer_store_event which is to > be called by anyone that doesn't do flow control properly. It would > stop putting things in the buffer when the buffer is (say) 3/4 full. That's what I have answered to Eli, so we're in agreement :-) > The file notification code must have a "check all files we are > polling" facility, for when file events are not available. Perhaps > this is buried in a polling loop, but it could be made separately > callable. I don't believe we can implement something at filenotify.el level. It is up to the applications to handle lost events. autorevert could fall back to polling, and it could continue to trust file notification events when the situation becomes normal. How it is implement shall be the responsibility of the application. > I think that the correct response to discovering that file events have > been lost, is to do a one-off poll of every file. Perhaps we would > want to rate limit this, but that should be done by *deferring* a > poll-all, not by *skipping* one, as skipping would introduce a race > that might lose a buffer revert. But I don't think this is actually > necessary. In any case no keyboard events will be lost. For autorevert (as example), using polling would sync all buffers towards the real state of the file on disk. Restarting file notification later on wouldn't be a problem. > An alternative would be to turn off inotify entirely and just switch > back to polling. But we wouldn't want to do that permanently; when > things have calmed down we want emacs to back to quiescently waiting > for file events. Exactly. > So there would want to be some kind of timer there, and the system > would have two modes. It seems simpler to me to have only one mode. > Writing the code to switch modes and coordinate everything seems > error-prone to me. Timer doesn't sound good to me. A better approach might be, if the file notification libraries send a "back to normal" triger, perhaps also via a callback. > Ian. Best regards, Michael.