Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 18:59:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 13:59:18 2022
Received: from localhost ([127.0.0.1]:45868 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nC4Yf-00079Z-I6
for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 13:59:18 -0500
Received: from permutation-city.chiark.greenend.org.uk
([212.13.197.230]:50362 helo=chiark.greenend.org.uk ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ijackson@HIDDEN>) id 1nC4Yd-00079Q-De
for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 13:59:16 -0500
Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local
(return-path ijackson@HIDDEN)
id 1nC4Ya-0002DP-LT; Mon, 24 Jan 2022 18:59:12 +0000
From: Ian Jackson <ijackson@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25070.63232.560314.823060@HIDDEN>
Date: Mon, 24 Jan 2022 18:59:12 +0000
To: Michael Albinus <michael.albinus@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
In-Reply-To: <87bl01rrmu.fsf@HIDDEN>
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
<25068.23625.512978.147194@HIDDEN>
<87a6fntgfh.fsf@HIDDEN>
<25069.23134.887206.241281@HIDDEN>
<877daqtnkw.fsf@HIDDEN>
<25069.40682.688423.883151@HIDDEN>
<87lez5ry92.fsf@HIDDEN>
<25070.51632.699234.228230@HIDDEN>
<87bl01rrmu.fsf@HIDDEN>
X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu)
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 53432
Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Michael Albinus writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]"):
> Ian Jackson <ijackson@HIDDEN> writes:
> > 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).
Oh, no need to apologise! It is very easy when discussing such
complicated things for people to misunderstand each other. I just
meant to clarify.
> > 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.
Right, I think you are suggesting that the "some file event got lost"
notification should bubble up to autorevert. Either directly, or via
filenotify, I guess - not sure which you are suggesting would be
better.
That sounds correct to me.
> > 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.
Precisely.
> > 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.
Let me consider the semantics of these notifications you are
suggesting in a bit more detail. I hope you will forgive the
resulting screed:
As I understand your proposal, the system starts in "normal" state.
In "normal" state, the file notification system should promise that if
1. a file notification is set up
2. subsequently, that file is modified
then the file notification system will make one of these callbacks
A. file notification event
B. "file notifications not working" callback
(And, I gyuess, that this will be done "reasonably promptly" in some
sense; I'm not sure if we need to define this.)
If B happens then the system is now in "non-working" state. In
non-working state, all bets are off. Users like autorevert must take
alternative measures.
At some point, the file notification system will make a "file
notifications working again now" callback. I think this has to
promise that, if:
1a. a file notification was set up
1b. the "notifications working" callback was made more recently
than any "notifications not working" callback
(in either order) and then *subsequently*
2. a relevant file is notified
then a notification will occur, as above. Obviously it can't sensibly
make guarantees about what happened before the "working" notifcation.
How must a user of this API respond ? Consider autorevert. Suppose
the notifications were declared "non-working" and autorevert resorted
to polling.
When autorevert is told things are working again, it wants to go back
to not polling. But it doesn't know whether notifications were lost
between its last poll, and the file notifications becoming normal
again. There might be a few leftover lost events.
So autorevert must poll every file again, once. I think it makes most
sense to do this immediately, rather than wait for the next poll
interval. That allows autorevert to avoid a confusing special-case
transitional state where it is not polling but still has one poll to
do - and it means the user gets the buffers reverted as soon as
possible rather than after a timeout.
Now, consider the behaviour of the file notification system.
In practice, inotify.c will probably want to declare itself working as
soon as the event buffer it is writing to becomes empty. Doing so
sooner merely imposes more load on a busy emacs; doing so later
degrades the user experience by having the emacs unnecessarily wait
before catching up with the work that needs to be done.
What this means is that the file notification system is only in the
"non-working" state when emacs is too busy handling important events
to catch its breath and handle file notifications. Ie, only when
emacs is not idle.
In this state, we do not actually want to poll for file notifications!
It doesn't make sense to make this fire off a timer.
So autorevert does not actually need to do anything with the "not
working" notification. It should wait for the "working again"
notification, and respond by polling all the files exactly once each.
I think a similar situation will arise for other kinds of event
generation. So we don't actually need two separate notifications.
We only need one, which means: "err, sorry, it turns out things
weren't working, but I think they're OK now - and I'll let you know
again if not".
The result of my approach as I describe above will be an emacs which,
when overloaded, suspends file event handling in order to handle user
input, but which promptly catches up with deferred work when it can.
--
Ian Jackson <ijackson@HIDDEN> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 17:25:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 12:25:48 2022 Received: from localhost ([127.0.0.1]:45632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC36C-0006BX-1f for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 12:25:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:56930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nC368-0006BA-H8 for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 12:25:46 -0500 Received: from [2001:470:142:3::e] (port=42290 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 <eliz@HIDDEN>) id 1nC361-0000am-Ao; Mon, 24 Jan 2022 12:25:38 -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=+uXlwTttGl8oMwZ9VqaUOhckCLj5s6wlJo8kcPYG2Co=; b=KiHnMgb+dXop mf8D+a0HxZlt/5t/Q3dRnNUrYkRJsQPVnwRzoxSy6PKOK98P9cy1uiaCAZL1ZigX5L3x57w6gqvnY gTdhVuj6Osd2tdWScUNTAi/Wz5Ef3T89K1Rf5xkRbqCgJs1vXJauTIafaQ4b4BxHIAr0FOgi/Mqjb pA3gRVtEpqD2NKCXfXPjPp8Wl+b2f7lk4a1R/q5uX+7C2iq7qZ27hfYKFbX7gjszjkREjT2AGZiP/ P7Z6mrzIuziZ31eZvNSCqZnUh9mhpaJW9LRTH0D8NsR2VvEmauc9a6ppKy2clodRbiKrH0wAEriRT dm/0U6o/SPQpTh4Aj9t/rw==; Received: from [87.69.77.57] (port=2829 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nC35e-0002Nu-BG; Mon, 24 Jan 2022 12:25:35 -0500 Date: Mon, 24 Jan 2022 19:25:00 +0200 Message-Id: <83a6fljbbn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Michael Albinus <michael.albinus@HIDDEN> In-Reply-To: <877daprrbn.fsf@HIDDEN> (message from Michael Albinus on Mon, 24 Jan 2022 18:12:12 +0100) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> <83k0epji6b.fsf@HIDDEN> <87h79trvt6.fsf@HIDDEN> <83fspdjcu3.fsf@HIDDEN> <877daprrbn.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Michael Albinus <michael.albinus@HIDDEN> > Cc: ijackson@HIDDEN, luangruo@HIDDEN, > 53432 <at> debbugs.gnu.org > Date: Mon, 24 Jan 2022 18:12:12 +0100 > > >> "Key strokes first!" :-) > > > > But it isn't only the key strokes, it's also all the events sent to us > > by the window-system. Now tell me why, say, an expose event should be > > more important than a file-notification event, and not the other way > > around? > > After all, Emacs is still a text editor, isn't it? Key strokes and mouse > events are the most important events, I believe. I agree, but since window-system events come from the same source as keys and mouse, we don't have a good way of processing "keys and mouse first", do we? We can only process everything that comes from the read_socket_hook before file notification (which would mean "keys, mouse, and window-system events first"), or the other way around. So the question whether a window-system event is more or less important than a file-notification event still stands, and has no easy solution if we start reading events from two queues instead of just one. > As rule of thumb, I would discriminate all events, which can aarive as > burst, and which are already known to be lost sometimes. D-Bus and file > notification events. If we classify other events into this category - no > problem. That's okay (and note that w32notify already does drop excess events on the floor).
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 17:12:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 12:12:23 2022 Received: from localhost ([127.0.0.1]:45557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC2tD-0003Wy-EL for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 12:12:23 -0500 Received: from mout.gmx.net ([212.227.17.20]:38395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1nC2tC-0003Wk-GP for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 12:12:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643044334; bh=HdKfCqkJXXPVz5y6hxyPghkPF2RyY8bPzi/dFrMfuPc=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=S6WhDNMsPBBqoMlo1legmsTXZvMiZBixpwRv8Ualw0hkzhaq0Mtl89+tWFdxtPtRo Gmf+XJqptBquebCyalrkZo/rqQwOjoeW8yDxznB+DDrKzqiFTrFCyjYOmqo4Tns2ZE za5O25Eew3udljXUOyaDzlmj2WK7Wcbt1hdMeFGo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([79.140.118.216]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MXp9Y-1mmgMr3ILs-00YDH7; Mon, 24 Jan 2022 18:12:13 +0100 From: Michael Albinus <michael.albinus@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> <83k0epji6b.fsf@HIDDEN> <87h79trvt6.fsf@HIDDEN> <83fspdjcu3.fsf@HIDDEN> Date: Mon, 24 Jan 2022 18:12:12 +0100 In-Reply-To: <83fspdjcu3.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 24 Jan 2022 18:52:20 +0200") Message-ID: <877daprrbn.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:HVu+CFFD8MAjR0cWQoK9gEvJ1TDnoMjHi7ExL+L9yki0oUBTyQL bknnKHHCWXaFztLycHDsCs07G5UY6TN9YFK4IdSayDOTNKSqyQHCTWDzzdYNEkMTm0QNf9p aqrCgm8F8mP4e+kwEf34oKN3hG1ZuwYlFxj6zg0V5kwTR4L0F88ufUu1FgGsevFKBTUoKac XLqD2i3bc/1LgNyYAkoIQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:Q7IV3/DepSg=:c/bUkn8zhXdnzlGQUEDeqr XBEF77A09y05NTHcWoa+G5H19xc9mid318H56/3vyfGuUadjoJPiw/JThJUMDwegbQZdyL3O6 VOMW2L3CK5HtzvF/Cu2hdKJBNdf2oVWwDAK8FeoCkn4Z8MAFiUr/kbIfIuw7nHcSW9UQiofuV M4MUuZ7RbWStOEUULcS9n1pJOEpI8+2t2bXjSvYJXJZEHdWWJX0eqymJqYvFahYcOrw7LvTsm QanTAI2ntn5P8hFmuvLHgfP+gsoF9IxrnhqYkwYh7DzZUCb5QaqS7c05Lg+mRZuDmBBXxzS0G l0WIGe3rsBXehu0gHgvJYw/Nbk2hMsgDhOuk5flUE9DC50wuNOVeKdA2SNsKPJPyl64kridov Qeya6/g2RIRDE5SqTS+UR2sgnY/XRFwrcJswYqTpqWucbJcH2Uq2iXlSOSzzfRRWXXoIVSQVe xfbapXDrruFw6frYb4DlKXkYDbDVU2VvjqLI5CgLx/RWMAn1gky84GVr/h8oWSJGEBeL3cbrr 4oJq/w7M9wewYhgfXcqS0OB/7lUXSArruF5h+mL1Oh/afcqYDBTR5AHiNmvbNgupNEiDK0LWg 0OxgbopIcoGgTrG7MauDu26PR2gO9idJHPWqwKTs0xqj+s2Mu6n5a3wTNYRrL6WDfo0WYjg+M IBZY3tACQ5p5spNSBWcr7nT97vUQO1xxVwUrsr+PGWlg8t5UWv/3SGTuL0CxND0wm/LZXkVKy 9N0Syqkm47DT2cmPnzeDvS5LPf+ji1CAx+uUhiv3iB8BKBQvg80l3cOalV3mjO3lqglMFl8b4 dQ4g3AbpiY0UiTBJLDZKjc2APrGxVeXJ17/Z/bkR7v37qdLVaVFBVWTmuT+1x5NUabPdCOdGM iD/kMrEFj1GTLQUuJDS2OaG7g01+Y5W/irxNDptc+Yu2pnSDF4Si93ULxdOEPeAhesH/Z99S+ nzskyuiRvPLDJNdIx1xd5JVCSycPmMAEVHb/9Xdf5IAMqLw+fp1upWZaVBIwsqGwKOotGTgEg 0W/y21kvJ90kstpH3bkCku6qZITw/NvvgNjK7BWfYiaOIAApPg5OxqKQjV9JY22sdiYSeFTDD F6PdoSh4Rh/BYw= Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: Hi Eli, >> > But the disadvantage is that we will immediately be facing a problem >> > of priority in handling input from more than one source. >> >> "Key strokes first!" :-) > > But it isn't only the key strokes, it's also all the events sent to us > by the window-system. Now tell me why, say, an expose event should be > more important than a file-notification event, and not the other way > around? After all, Emacs is still a text editor, isn't it? Key strokes and mouse events are the most important events, I believe. As rule of thumb, I would discriminate all events, which can aarive as burst, and which are already known to be lost sometimes. D-Bus and file notification events. If we classify other events into this category - no problem. >> An alternative approach could be to restrict how many burst events are >> put into the beyboard buffer. Let's say that D-Bus and file notificatio= n >> events are allowed to fill that buffer until (KBD_BUFFER_SIZE - 512) >> events (arbitrary number). This would let place for key strokes, mouse >> events and alike. > > That's what Po Lu was suggesting, AFAIU: limit the number of queued > file-notification events to not more than some threshold. Yep. And Ian is also on the same way, AFAIU. Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 17:05:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 12:05:41 2022 Received: from localhost ([127.0.0.1]:45541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC2mi-0003M9-Kj for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 12:05:41 -0500 Received: from mout.gmx.net ([212.227.15.18]:36099) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1nC2mg-0003Lq-Cv for 53432 <at> 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 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 From: Michael Albinus <michael.albinus@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> <25070.51632.699234.228230@HIDDEN> Date: Mon, 24 Jan 2022 18:05:29 +0100 In-Reply-To: <25070.51632.699234.228230@HIDDEN> (Ian Jackson's message of "Mon, 24 Jan 2022 15:45:52 +0000") Message-ID: <87bl01rrmu.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:YYxoExyuFFBbApdfMYHwCGGTQ11vG0lUOikMDpJlkxERbZ/+KlN CSneIDT46SQ54JnKQbKayXjPZZrGZ21E3gyHiD9u/iNQpNXZommJ+LR6BU3gCICK7mf0ysa +m/Kp0ilGbDVz2OnsZRC3CdYldklGp/ExajZoCfRSMyBp7eJEokPrSn1XTOpLysBpHpt+uP qLEOhGzm5/8TmHJUCY7NQ== X-Spam-Flag: NO 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+Nt0P 9pDveH4CXHEqpCFTW6CdU4hA2k/GL9xaJmzq4ogOdaXtEYMG34bMoyuwiR5W09NuM1+B1x0pe JDFuS0JGtGTNZDmyOwM13WR4Eked06/hY/2lDPe/2NdEJfQrCacr+yPghRE+iGbRJ+yxHtkAz BD2qG+dLD4S1BXvHTPiGYuiEn+c9aGee4e3PbdKO0mtD+7tm6BDRmSjYEWxoEhMnobE15y3M8 a+G4zd2oQmeQHtbZEppWPDXc8JkQ0jMgU0q5DPzYauFDMfOJWvix6JVhXFYN39N1Jh2cRy0ci a+iGYuu6LP4+F0= Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53432 Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Ian Jackson <ijackson@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 16:52:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 11:52:43 2022 Received: from localhost ([127.0.0.1]:45520 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC2aB-0002yy-IX for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 11:52:43 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49100) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nC2aA-0002yf-02 for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 11:52:43 -0500 Received: from [2001:470:142:3::e] (port=41224 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 <eliz@HIDDEN>) id 1nC2a4-0003zx-9i; Mon, 24 Jan 2022 11:52:36 -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=+5iuL5MjudhL3dDwBE2uOFdp6KeWsVPFzjtFTNMbQCk=; b=CHMknGk4G97w kHhyMcJp2fjPjr701BMImADnIKqfIT/sTw2F5xq9OA9X3j4m4qy922i7H0O3lwneT7DQrhqI2Wqce 0XOMHR3X+C9eIgMnXxRfKGZAcVPtckg5J/aQKmSxDp0L1zFBoBhet4fGddtHtnZnsBEQHA5vdb04p C2w9O0CXoSZwLsUN3VgKIWb6AHY/EU2MkyfpKvkFAXAE03ivcsZuTXAI/WUnCAcrub+gXrDKTBD24 syIHJ5UbO8hc4P9eCp+Cx7/U8bHejO9Y/Vvpc8r6bG/BU16bRwh20pw6WNr5JTuwBY2TLWhP0Yklp etMj5q37PHmrP6GA/v0/bA==; Received: from [87.69.77.57] (port=4810 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nC2a3-0000NI-Gt; Mon, 24 Jan 2022 11:52:36 -0500 Date: Mon, 24 Jan 2022 18:52:20 +0200 Message-Id: <83fspdjcu3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Michael Albinus <michael.albinus@HIDDEN> In-Reply-To: <87h79trvt6.fsf@HIDDEN> (message from Michael Albinus on Mon, 24 Jan 2022 16:35:17 +0100) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> <83k0epji6b.fsf@HIDDEN> <87h79trvt6.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Michael Albinus <michael.albinus@HIDDEN> > Cc: ijackson@HIDDEN, luangruo@HIDDEN, > 53432 <at> debbugs.gnu.org > Date: Mon, 24 Jan 2022 16:35:17 +0100 > > >> 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. > > > > But the disadvantage is that we will immediately be facing a problem > > of priority in handling input from more than one source. > > "Key strokes first!" :-) But it isn't only the key strokes, it's also all the events sent to us by the window-system. Now tell me why, say, an expose event should be more important than a file-notification event, and not the other way around? > An alternative approach could be to restrict how many burst events are > put into the beyboard buffer. Let's say that D-Bus and file notification > events are allowed to fill that buffer until (KBD_BUFFER_SIZE - 512) > events (arbitrary number). This would let place for key strokes, mouse > events and alike. That's what Po Lu was suggesting, AFAIU: limit the number of queued file-notification events to not more than some threshold.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 15:45:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 10:45:58 2022
Received: from localhost ([127.0.0.1]:45399 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nC1Xa-0002im-6h
for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 10:45:58 -0500
Received: from permutation-city.chiark.greenend.org.uk
([212.13.197.230]:36910 helo=chiark.greenend.org.uk ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ijackson@HIDDEN>) id 1nC1XY-0002id-Dy
for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 10:45:57 -0500
Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local
(return-path ijackson@HIDDEN)
id 1nC1XV-0000CZ-FN; Mon, 24 Jan 2022 15:45:53 +0000
From: Ian Jackson <ijackson@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25070.51632.699234.228230@HIDDEN>
Date: Mon, 24 Jan 2022 15:45:52 +0000
To: Michael Albinus <michael.albinus@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
In-Reply-To: <87lez5ry92.fsf@HIDDEN>
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
<25068.23625.512978.147194@HIDDEN>
<87a6fntgfh.fsf@HIDDEN>
<25069.23134.887206.241281@HIDDEN>
<877daqtnkw.fsf@HIDDEN>
<25069.40682.688423.883151@HIDDEN>
<87lez5ry92.fsf@HIDDEN>
X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu)
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 53432
Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Michael Albinus writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]"):
> Ian Jackson <ijackson@HIDDEN> writes:
> > I guess we probably want a "file notifications might have been missed"
> > callback. Having it be a callback like a normal file event callback
> > will probably make it easiest to deal with.
>
> Yep.
> > I don't think separating out the input buffers would remove that
> > requirement. Ie, the ability to cope correctly with a flood of events
> > (of whatever kind) will remain necessary.
>
> 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 notification
> 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.
[reordered slightly:]
> 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.
> > I think every one of these other event sources ought to be able to
> > partake of this scheme (adding their own hooks like I proposed for
> > inotify) without undue difficulty.
>
> 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.
> > The result would be that if any of the buffers overflowed, we would
> > stop processing inotify events altogether until emacs has caught up
> > with the user's keyboard input, and then (via the file notification
> > "maybe lost" callback, do one check on every file which we might want
> > to revert).
>
> 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.
And discarding events at a lower layer helps performance because it
means they don't need to be transformed/analysed/etc. The performance
of event processing is particularly important in the case when things
are stressed and overloaded.
But I don't think this optimisation, at this level, is inherently
*necessary* for correct operation.
> > Would it be OK to postpone splitting this out ? I don't think
> > splitting this up is necessary to fix these lost notifications.
>
> Not to fix lost events. But it helps to fix lost keyboard strokes.
It will help to fix lost keystrokes only if we don't plan to fix the
uncontrolled spew from the other event sources. But it is easier to
fix the lost keystrokes:
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.
The plan would be to replace all calls to this function eventually.
> > I guess the next thing I should do is go and read the file
> > notification lisp code to see how a "please do a one-off poll"
> > callback could be implemented.
>
> Hmm. We are still in different camps about the approach ...
I am confused.
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 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.
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.
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.
Ian.
--
Ian Jackson <ijackson@HIDDEN> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 15:35:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 10:35:30 2022 Received: from localhost ([127.0.0.1]:45383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC1NR-0002Rd-Sh for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 10:35:30 -0500 Received: from mout.gmx.net ([212.227.17.22]:55515) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1nC1NP-0002RP-9V for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 10:35:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1643038519; bh=BFnDYN/vzxgcyhRnFySxk8vottL7qYrqe+a0ZNvVXyI=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=FbySiUgIryRV/epVJiXOVZf5ihtQbYpWuvJsuq0NqLknnrUvb0fkzBs+bH0eEY6EZ mc1Z2MS5vyRWL53btGBaFFkOT94E70KDw10iQ4KVTkEq2u3M1gDP1fyMGEHcKR3L6S bORJy/Gx0PfE/0RQ/RbFCOGJ6+l+5Sk0HqzaUYNI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([79.140.118.216]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M26r3-1nA6V53NeL-002V37; Mon, 24 Jan 2022 16:35:18 +0100 From: Michael Albinus <michael.albinus@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> <83k0epji6b.fsf@HIDDEN> Date: Mon, 24 Jan 2022 16:35:17 +0100 In-Reply-To: <83k0epji6b.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 24 Jan 2022 16:57:00 +0200") Message-ID: <87h79trvt6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:3cLFzfWXvpjUtEShjPyDPNkg4plMMuNzdCdt3Mpui+P4Niywr76 oRmAwZEq7jCLe+WfAtKk81k7ts2QM9KTuuxeYgI5xe8OxsPf+xqyPeCWpDVOHUUbZGqRcUm QDu4vGTPfLQLezwoeUjHCNjbJ2pInZM236EzfbXmXcUYomyPVnfoFrQZMCJmMM9DPr1jcZ1 Hwrvgt2YRuTfFYqUG072Q== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:k7cSYSmjVPs=:QYiZ6j0FRuohW3XNbwuD36 8UaneLACfImR3GthvXBRd1dMyAoOTN9L+0Gf/D0bSVqNgDu6qwrx9YfYwLcEkL12oHbwC2my3 ywuWBh0AW7ffDDM75B7t0Eub83Dz3qkL+xtg6LEh3lSUuo/Su4mH5AN1f95QcCPRLHF/lbsTM yzOS9nlndrvLDT5zocdtQ/1H1vWjdttYQUdSFNp+Xl7q7cZAYCnAzRjruO3g47LO5Yu6g46tF pRMSYBuI8JxZPVRMnpzA+AxwwrTJ7c0Ix9JfvuaZSpIvJBtV/uX3QV2QUhj7O2zVXmgUbLJb9 v4/TVmynK86TkASpaStinKn3OU9IuMAxw8MKJHP1/efn0mZDikNQS40IWZzKbmKzljLSqxxga 0WXnmt7SzuhEzfPsUV2+wbQsfMs5F+qKQLvm0KlVUTHFQGhyHPXo22o8A7a1uBfYFXdM8/JU/ LmfZBX3OOpb6Psdb2mRsdQqkRILsCaHv+wpF3U8FipWL1tbQFcm1GjVYhtiKy8L1I2figgWpC arI3EZrxsAkXuF4pBUj+Rs3a+KbP5mUBr/iQOa3DMTUYYlXji4Z5srdC+dHhSPYqGSURZGVhX Sqjd3WFV7+kbyjOfqlnFlPhjfPNojM0KvViA2zzy/hWVbL9g70gF1AA0Z8fi1WFcRibIDEnXc AC1KcOk3kpbGd7eMb3EbQp4G39vsi090LM7wPQ/wy82lDSe6dnUWA+9qt8zV+AlxM5+bkpby6 WwJ8Xw+w7kXLShMQDNnE58XlPV6+UWkmxbXaeBq4l+D5lV4bV0IxIDOLd9e+TZSW4nFCYGPVH fzozlg14hTA+xQMV/s04XkRJq528fv/WciXSAs9fXoHdl+NXsfS02dK8AJrghCgNut4ts+xWf maDCSOrN2lp87Y2ENTW/gsHwaFSe6gRmawruXOerpRsXwiINXStS5FQNe44kVH4b7sE9Kxorz IHKLMh+ki+B865pSuFkwqLKezQk02n0dSZ45vX+c4ICWDvArWe4WR+d/jZheW/F1swCoxwzvZ vavqwF5v+Nj/PzCKxBfmXQvk0cZUM1GTdONpZIhs3PmReX6u/mtngBEuj79Kj/cKsm59xv5XE HPZiHOyJULfdbQ= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: Hi Eli, >> 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. > > But the disadvantage is that we will immediately be facing a problem > of priority in handling input from more than one source. "Key strokes first!" :-) An alternative approach could be to restrict how many burst events are put into the beyboard buffer. Let's say that D-Bus and file notification events are allowed to fill that buffer until (KBD_BUFFER_SIZE - 512) events (arbitrary number). This would let place for key strokes, mouse events and alike. Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 14:57:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 09:57:22 2022 Received: from localhost ([127.0.0.1]:45342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nC0mY-0001R6-MK for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:57:22 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50680) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nC0mW-0001Qq-Ds for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:57:20 -0500 Received: from [2001:470:142:3::e] (port=38394 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 <eliz@HIDDEN>) id 1nC0mQ-00035N-GW; Mon, 24 Jan 2022 09:57:14 -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=tBwbuKlrohkpJ4JPGkMT0ey1OE3Fes6ErQQgsTK/cLs=; b=l71VYT3XVw/e ueUHlUDS/iU8KxQKT6MRlAywlIru5LL8wTSvHqUALv3s2gKl0gpY7NPW6fTAVLpm2EauwA1aZypWo nC/EEkpoYM8iNXYgNulHyR+FZIIr083pZfQQXI6/ET9JYiyJGaC3LSbBzYZD0O7ZuPxa9CP15P0UD L82Uaq3EY3nvFXjENjM4+ZtC7g2VGkWvw6RlUyY26nIh/PnPDox+hyCjxl5kP9w6YpTkZhJXU7NZz EybYybApLXYD1Y0neSqXORToNxDXwT3FveTPyZTmBt8+X8oVuVNcGer5QOwwMz0GhPbBVVl/vOyeC MjLEEL6k757PlsiQ/SZ3EA==; Received: from [87.69.77.57] (port=1779 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nC0mP-0003Si-7t; Mon, 24 Jan 2022 09:57:14 -0500 Date: Mon, 24 Jan 2022 16:57:00 +0200 Message-Id: <83k0epji6b.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Michael Albinus <michael.albinus@HIDDEN> In-Reply-To: <87lez5ry92.fsf@HIDDEN> (message from Michael Albinus on Mon, 24 Jan 2022 15:42:33 +0100) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> <87lez5ry92.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Michael Albinus <michael.albinus@HIDDEN> > Date: Mon, 24 Jan 2022 15:42:33 +0100 > Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org > > 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. But the disadvantage is that we will immediately be facing a problem of priority in handling input from more than one source.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 14:42:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 24 09:42:45 2022
Received: from localhost ([127.0.0.1]:42715 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nC0YO-0000Mq-Mt
for submit <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:42:45 -0500
Received: from mout.gmx.net ([212.227.17.21]:50547)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <michael.albinus@HIDDEN>) id 1nC0YN-0000Ma-2v
for 53432 <at> debbugs.gnu.org; Mon, 24 Jan 2022 09:42:44 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
s=badeba3b8450; t=1643035354;
bh=Tb/JAbjMAJv+5S1Yq0EvixVaF8E+rzZcNsjr6nM9dZg=;
h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To;
b=imgsEl1A5YmXS9VKiCWcCYd/eKGbbqaglEEbiKZwP21ndT/yAPkH9nQUUH9kQqGvF
PebtsXL/HROuvNrjqCAgOglcZj2zAuzbi3yW1aUaJyovM5rHcaY7IOgStKLc1gqWJJ
Y7YelQCatjlTQsqQ0cQbk4DneF9jndN7x31oYUMs=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from gandalf.gmx.de ([79.140.118.216]) by mail.gmx.net (mrgmx105
[212.227.17.168]) with ESMTPSA (Nemesis) id 1M6UZl-1nESSB0dxp-006sxj; Mon, 24
Jan 2022 15:42:34 +0100
From: Michael Albinus <michael.albinus@HIDDEN>
To: Ian Jackson <ijackson@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
<25068.23625.512978.147194@HIDDEN>
<87a6fntgfh.fsf@HIDDEN>
<25069.23134.887206.241281@HIDDEN>
<877daqtnkw.fsf@HIDDEN>
<25069.40682.688423.883151@HIDDEN>
Date: Mon, 24 Jan 2022 15:42:33 +0100
In-Reply-To: <25069.40682.688423.883151@HIDDEN> (Ian Jackson's
message of "Sun, 23 Jan 2022 18:31:06 +0000")
Message-ID: <87lez5ry92.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Provags-ID: V03:K1:ay6jQvPQ9cJKa8ibPaGYeka87RXfQ673jwpDiQr5OZO0rkVtAm8
3Z1cQ+xtdotHmVsWtkIQCIJY7X1w4+Qpo4tNfqgJBcbEeF760NgTSoYPYu1e+9B0Jblpv4p
m3vRv6hl7p2fr556chfJe9jULyiUQk8APK6dVeSA35X5Z7Axkfa0qQOi7OV7QQ9qrsFWxCk
040HuUcOUjqnlyu9+7+tA==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:hxifmJACUmY=:juuIt4yR6KbFYxbqGXVUY5
szu+4nuOdGb6ZhIYkd9IrqIJ6EONpaFALkXi3XDREOqfLep/wOE0APzulQvcSk3PL0yaTSi6C
N7RDC2CpNIbRHX1+7vQTk3Q+9TmMR+IcVG6DDiwrFVXj/cnmhRTNggIhq18a3O2qMFQ0L+Uwk
h2TYZ9lBFmgRtMgzR9xE+lRL2SOQCJPqYZDyU0wjW3zcB+265mntaA+QIdFa+ynsfK7w7231M
szNzgRJ3gw2CZCuRZxxRkR4T8m+N145iM67yzWLz+ZJZW1+a4+K9uQzWQxOjGO5auVKAOu6Jt
nef5spL2zILUoicFU2+26iVUfFyBbOjgqaa2exmyMVUOeZVOtTLCJB94J6MroeZRXTGZEb7F5
wDKBo6s8nAYxLl9EAl8bLnpHvisHKgvWda+7YvfEUXiXuv+T3KSXTjCIQG0mBbMIjsXXMqop0
rG8tE24YcTuutuih+LxKLQxBgyckr8JpyCEySTU0wCVcVb/U1o6VvqdYigxPVInVgEr/xDdsH
rvetkdt5bzlGJoXqaIfDr+4Sm9gpCLMmhsngE7rpmn066bjthjmlW8xhnDgZ7mRKxlinzdXQP
snMF41XPB42Qnf/Yu9OZqbH8Q3qw7vxJxntt6KnI9kRgDZTG/k3lYFOTDtKugCqq92x/kBXmS
RtdWBuWQhtDXkwucwEPb3+7sNE9x2K7DZiQbN2TkS5HkKGLSQ8K5UBtzDHaUlpqkn2KdIwNP2
LolCGb7X0Yuzi/NRX68JLLuptbfz9LqJHxu70LsGVV37lYuizYBAqnTKlVt4no8TsmK1qzNQm
E5++92dPX2DZIPLb5oWMP2GWZroRcUQsWu5YBhnH8pnaO0Mlyvo/rzJ6ytQ78tgxq80lZcV/H
eTLKx3vEELoum6swBrdaENvs0l9Sl9CaFGqBJu3M8ojMBDGAa4+MtQ1ei6bNER/mUryWgUmnD
DtimY6Bv8K1D9I6FAugpanshDKkmKNfpzkXoDuMWKnjAufAcBYRTgZ0VvKa9XpyBcaD61EUVI
VGDUWY6KqN7s3UbnSGDHtOF4RFcVt7MB18eMnViu5fTdgb+P5QUTn3hWHqMc8w1HfcZCrqO41
+yfxsGYs8WsOb8=
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 53432
Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
Ian Jackson <ijackson@HIDDEN> writes:
> Hi. Thanks for your really helpful reply!
Hi Ian,
> I guess we probably want a "file notifications might have been missed"
> callback. Having it be a callback like a normal file event callback
> will probably make it easiest to deal with.
Yep.
> Another possibility would be simply to fire every file notification
> event with a dummy set of information. But that would probably
> involve changing a lot more code.
Yes, and it might also be a performance degradation.
>> For this, I have no opinion. However, I remember vaguely that Stefan
>> said once that we shall not (mis-)use the keyboard buffer for incoming
>> events, like from file notification or from D-Bus. Another mechanism is
>> needed. This idea hasn't been implemented.
>
> Hrm. I don't think I have an opinion about this. But I think the
> design with a fixed size buffer, implying that input to the buffer
> needs to be suspended and resumed, means that *every* piece of code
> that might write into this buffer must also participate in the flow
> control mechanism.
>
> I don't think separating out the input buffers would remove that
> requirement. Ie, the ability to cope correctly with a flood of events
> (of whatever kind) will remain necessary.
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 notification
events, such a check is needed at fewer places.
>> The following packages inject events via the keyboard buffer:
>> dbusbind.c, gfilenotify.c, inotify.c, kqueue.c, w32notify.c. All of the=
m
>> could see a burst of incoming events. It isn't just an inotify problem.
>
> Yes. How alarming. Well, this is a bigger problem.
>
> From my personal point of view I have effort available to fix inotify
> and kqueue, provided we can agree a way forward. I looked at kqueue.c
> and it writes only file notification events to the buffer, so the same
> "file notifications possibly missed" callback would suffice.
Yes. Same also for dbusbind.c and gfilenotify.c. For w32notify.c I'm not
sure, but likely also the same situation.
> But I think the keyboard buffer suspend/resume, with
> event-generating-code specific callbacks for suspend
> ("hold_keyboard_input" etc. calls in "kbd_buffer_store_buffered_event")
> and resume (in "kbd_buffer_get_event") is not a terrible design.
>
> I think every one of these other event sources ought to be able to
> partake of this scheme (adding their own hooks like I proposed for
> inotify) without undue difficulty.
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.
> The alternative would seem to be some kind of dynamic registration
> system. As I say, splitting the event input buffer into "keyboard"
> and "other things" doesn't seem like it would obviate the need for
> this plubming.
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.
> I was imagining a callback hook into the inotify code for "keyboard
> buffer has become empty", which would check for "have we set the flag
> for lost events". If the flag was set, it would drain the inotify fd,
> make *one* "lost events" callback, and start reading the inotify fd
> again.
>
> The result would be that if any of the buffers overflowed, we would
> stop processing inotify events altogether until emacs has caught up
> with the user's keyboard input, and then (via the file notification
> "maybe lost" callback, do one check on every file which we might want
> to revert).
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.
>> > I definitely think we want to get (back) to the point where choosing
>> > the keyboard buffer size can be done purely with respect to
>> > performance considerations rather than worrying about lossage.
>>
>> As said above: perhaps it isn't the best idea to handle such events via
>> the keyboard buffer.
>
> Would it be OK to postpone splitting this out ? I don't think
> splitting this up is necessary to fix these lost notifications.
Not to fix lost events. But it helps to fix lost keyboard strokes.
> I think I will let experts on glib, and the glib code in emacs, handle
> this.
>
> I guess if I'm fixing this for inotify, I should at least add a
> comment next to kbd_buffer_store_event saying "you may not call this
> unless you participate in the flow control protocol" and add FIXMEs to
> the call sites that currently don't.
>
> All of those use cases will have the practical consequences of these
> bugs reduced by using a bigger buffer.
>
> I guess the next thing I should do is go and read the file
> notification lisp code to see how a "please do a one-off poll"
> callback could be implemented.
Hmm. We are still in different camps about the approach ...
> Ian.
Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 00:42:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 19:42:32 2022 Received: from localhost ([127.0.0.1]:41556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBnRI-0001Rv-Ln for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 19:42:32 -0500 Received: from sonic302-22.consmr.mail.ne1.yahoo.com ([66.163.186.148]:44934) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nBnRG-0001Rg-IZ for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 19:42:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642984943; bh=1aEf/Y6m4svUFBEC7nWrQwjBgg1AHhMesRj1JKHYwvM=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Prtj8hKqGINGlLWBsmSAVViTyneo9N2mjR/POk6IhPS0kvvUztb0kKFs5yhFJ99PPp54EA/6268BdtjbcTRNdAJOr6vCZZOOdDjIti/ljFzzNWP8maB8HulPRETTCr/3lwWsKcF6yoTgp5uF3qd8sAGoA4LyBt/oFkWtNDJ+6HseoKhsYF5CLo9BiahrW2L2j92MNAy5BRsBk7S88iU24tlCqnfsynbvu4zLBfuM8530wNTaESpfi3tEL4QF9wsnGSllJfLAT386kFlVGZnJ9ZqPcjRJZ5HI7KTrzZop78Pat6v/HlTwYMNZGcWaT8v5osMJHmuHRfD8ETtKIK6p8A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642984943; bh=p9BQLTY2Qvq2yzw+0Op84TJIbSR/hnqFB+He9rJEGe9=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=rHEVYHzDu61h3piJTrdIc3WvR/zy90nwv+dRn53ikRC1VDGscGn26sr1HoXD4pO9a/VbBtmOjla309nUOXrcXiG1I3rccKrudfc3SheypH2SE+AKuqWafQXAdBYlvip8yKTje3zATsbDW98cm9e9BZC4YICgf17cwmZ4ftT5EbVU9N16suGDhS9Bp9bKoyqU7LEdrg1z6ZE8bDgEjFmrIzloXCL5Y3oIpzK4KE33z25J7S13P/FbGnOxZu3Q3sA5exJgarVsy1pK54Vnvs4Yg4XSHUT2goU5KwmPG4DzgYi/uv7/z0gg1HOorKADR+wxixz103aWeCV5Uxz8lyhgiQ== X-YMail-OSG: GZ4yjM4VM1moloGB3KRxPdgACRe6Txpfca62cdscZzjS5CsLmY41c8Ey9FdL_7V uMR7YGAFBOVkkGxgXMcMHgcUvl.a5f8wvcqeFv9I.m_u44.1OPONPzB.T3G4wh1oSomestxqUqwk Wk7TcbO6D.Q6uTOoOpbT62VLMLWB78Oqw6ZPnpIrUZoJr.v6k5W_ydAUxCLXpZT10zMD1zVDr4RN IJbYBSUrBQZP1az6iM7hYLWz.ZMyEJXioHtB6uWi8fuy2F.3cY9J01zDckX40_vKNS9HDZkbDn6O UurZXwnX92PgzvfuSU0tZkwr2xEE_3iuBDbO00QxvxyCZ3WcBSd17Dk0B9wcn5O1TDv_jN0mI6OX qo6irhxHsj18Yg4M6PRdXtbngvFuEvHimfmeCXODyYnQF3EyLx2rLR_qlIpwQsKOP6qpW8voQLQ6 2c45dPhk0frNaqp9NyDQmUdV7R2UXC828ZtfG1j07FFQMFkQTpa9bV3a.lJ1a1fIIoaIFJ3ytd.P g1CV4V9jTpCxeSSAGrZsokid7a7XjwcAEXMw2k87SkbkgwPkzaef3EnAibv02x2tO_HEr0mopcYu dm.IU4xIEICcCJAp6P_nu5r4CNbwc6xNUS4e_zVr2HVqa8QJedyyNavGxYI9PVQGvigJsLnizKa5 3PFu5IvdjnqmPk18nLPK5W5GbTJoFwe78Uh5y_ipK3s9LVEsTMYc2N8V73GXlWdnSoBepURt1PjX t1.S00heVp0Lz_3fPy4A6gCZDAe7Foggjsouy29Yh0SWFehuWoU7aj5SOmxrGdEuEnhCr_UdIZTI FdKuA769bzdK0Yjz2WQHBwjHqbZedSUBpEk9jtYHIH1yRCR91kEdWRnJmcHi6NQxj_n78qBWzTY3 PgNFrHod27HlwN7d9iw7l1IJqFZeOKmFr5LI5qyenUYgEZSK02SbA9AGtgld8ll1UZAEzTZNrAa8 tMSDg8HVDwE2_QlM7Ua.dT_.K.t0.jwfEicgL.OB5SInUa8S_8eOZQPs8p0ZdgUDSux8nQW.a6fC dHuHBTAGWOsLw6LHUY.utYfSQEbu.2bu19SUmdIhmeYRH_QZu4hsJUh97_iTH6F4Oq7B6apgj0Wo mcJCUs9E8_ZVdpKIaAIBhBACI2FBR9GGUtE6oBGRjTYWSRrFdZJEcM1lq6QX6n1WxDwXKQr4EUJd 8Mhxh_MMVK59ggWtAzkA_I71umnWF4sYqLoxkiFIghEMescQ0Ly_JJ1l5tV37S0Nk2vjVOHyxI8s 5yK1Ad_1NfSGHypSa_z9zrK7nh3hAu3EIm_UcBkZL0GymyaRxS8bKHjhTlyNczqcrmBr4mmBQ82m H4k5s3IID.Bj193eNTJv8QiMs_jfxBy07D291WgGS3So145G18jr9aP0fwqpHcwZ3oiLr_OJY3X. A5cFF9LpcRn.WE68iSoJPN8rrVqyXAHTol_uctq7j0wT0ZF9kir.hSf8a6Wo70g_FTk9SIz03N_b 7ACyB5OssLXGROoGPcVCjFeQerG.kI34N4RfyTHxmSvPt8kmxEMea_ct9bs5zOsDBvIYWvN7Y_TZ OXC4q87swrkUjJKQhg3mWv2mW9e1UI1VhWU4cEZQgGFnuExUvT73oGv8XZYvVPSs0J2K7Lo3Ij6G 9XUGa6sz1LcdOisJHx__xmWP5CAZ6ehrkaXy7eVQbBA6rOxxo82SfwarMSYwMPmarllBrqJcEPPE 0rveo4E5WSjo.WO34KfnxDFGyGpFPwe8quLWVE0KL9_RXj6Wu_Jo1mzZjOy9Ybp0C5iN5GCmTEEx t2EvPv6IUL19WDisdHvG0c_BbWqjF6cSQ4Q5GEZcfESg8IWYUvAGmGX96KdJ3dbsC6TbuDtSZuJ1 xuPkmHeIe8melMdfIdA4rTZYLJdNYlSrC6WTPZAmdjJZXw.tgxITs8Ew1vWPsnldzbprzXwbBTKD 3gMhbXTNOyuwfdADn9YucS7HvI8Knvoynn_kvQUr45jVa5uCStVwv.Intn8BSgA2bTdfCEUoVpTc x40qVht9fWjTDqCy_nXoWJSJKBFsH8DMSRFOPrWPGuK.JTcA6fB6fwiW.tg_k3iFDmgNgB9Nvs7A L6MZ9gaAdGhB3L4fJbx9YNm9M.6YVGwHaY93O_FZVrYiBUzEe2X5TKjqbAERh9N0Kz.1Uxy4seWl Ero6J0lNU6rgpiMEOP81VHiYxLwqH5vIF6AXtXLDhJhq4yFtb.xQDRigYRP2sxwScVl12iOLMnEy N2dF8uoKpBjkw2.2Ufgek4dSDO5vuyolMZzQ6V6aZPRc07xl_oXLlnmP4 X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 24 Jan 2022 00:42:23 +0000 Received: by kubenode508.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 2f8aa6e893cdee6a3dc663dfbcdc8b01; Mon, 24 Jan 2022 00:42:18 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> <877daqtnkw.fsf@HIDDEN> <25069.40682.688423.883151@HIDDEN> Date: Mon, 24 Jan 2022 08:42:13 +0800 In-Reply-To: <25069.40682.688423.883151@HIDDEN> (Ian Jackson's message of "Sun, 23 Jan 2022 18:31:06 +0000") Message-ID: <87pmoiotga.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 340 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: 53432 <at> debbugs.gnu.org, Michael Albinus <michael.albinus@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Ian Jackson <ijackson@HIDDEN> writes: > I don't think my emacs (--with-toolkit=lucid) participates in dbus, > glib, or w32notify. Of course whatever scheme we come up with ought > to be structured so as to work for those. Your Emacs is probably built with D-Bus and GLib support. Choice of toolkit does not affect that.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 24 Jan 2022 00:26:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 19:26:44 2022 Received: from localhost ([127.0.0.1]:41550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBnC0-0000zi-3C for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 19:26:44 -0500 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 <luangruo@HIDDEN>) id 1nBnBx-0000zV-FV for 53432 <at> 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.2Hmo5h8XnMwwta2lDmWFvHxys6TYDV.kxGumy1LsumZeTnOZ ldDGGJl9LreFekQhT.1PfF0Sigr7nQQVWYj.iCU553ry.HyY_w0fLn3PPG_hNXdRKGytfQVks7Ey L6Uq_8Hlz81JrS8wvM_9s4cLHvYENSahgdiwEK8rUbS42FHJAM_T7hsXKITlhZ4m3oXR8OVAUiI_ TSzGVggJmRmVqMyYd8urXQJSErbkjRuRlOSsHv4C21vnaN2QtA1eRVhBbFlLFNzf8.QBEAek22lE HtZWq.KNdnGYzJm7TET7c0SDuonL6LuXS5u13gNoIX7KXFdHxdSX0Z8AGuDWr0D5GHdlCRy6nCQX 3eSviJDEzD1IE90ll.0ZFRgu79gzOrr5XZ72wfrDrmFa4sP.rTWOOOv_1QBG5qlOQOHE5l3oBQcw QS0HRuCbQFyB4oSeSsZc5SFYUYS2bOmlncuddHbJGXVgiQ5dqKbYsWON_tJUgE55MJ4rR9MpuZZs 6d3YJN.fzcKGES_cbd_MG587D6Izh_6hnqTBQIkUVXaW2o9XPX_.jPgMGkGf1_DdVnXJKCaj8iao 4GrBHht9VbdW6T3Vu8_FsMyWtjdopc8qCH4ga2SSGNlzbIopnVOPuEE.01UG9e_nlfQ82dTuwK3w 3hQuNv3ED1PXOrn_ZLuXexAOn5y4QIKq6p37ikFtcIBRWOTCqqk2qNvUHZ8HRSvrejdJVep6rT7A Um5Hb_Snd9MKxtmlnCFGaonPHxvUpasNz4B_S.ZVV8Mn_tabFVXlJAss01xf8eZvWiZ_upTAZDlC j.VzSp0TDEH66GAoUz6qiXyJtRnusb2MQOWEDZ6e7YT2IMTOt18aOSpTouRzR_EqaQKrDEwFzNf1 iSiToBIe8A1a9DgBwTWxNK.545n1wk_oJBm2Ppxuf42ouGY_dgZySaHYudw.y..Lwt_d__dbFxvN SG0LX.jbUasqlyx7sMXxegxY60ap1jGZDJybuxByvgiJrX1k1iSUoS.QbI0HoriRrqAXafKCA46U OCwbu1v.R9kRm2SIkFLliTAtZB192UrE2X1eebx1gK1QPs3y_yYIrBcIBQIiLxCs5.Ww5BWBHOaZ 4mTdv45rU.WcKiu0wU.2DuyhXPmtS1AI5VbBEA8MsRi57GodFXwnF267_3TujRCoxH4tvFuyRCi0 8oRYmzvOAyGgRQIOSkILzmtOS_ZD_wf.m2OoxZZQ1LR33T0i62IimfgSXTe5sojtiOxhvaV9Ghfc UIsJXrzsFaLXq1FiLOkvLXH46srI9BKRmTXHVWoWrss_cVWkkk0.1kqb40vUdt8kHQM371x0rWVZ _pukzXRiqyMMtA9V4AoS57KyGxQViurygJPOg6VNun0oXgbtUy9Wn4reTO19GGHmgnhGIegCVgJ6 t0.KO45gCGIEkvWpXGR2ZT6AWVEt8WN1wyRFRbmISXgBZRjfudjsmdjI- X-Sonic-MF: <luangruo@HIDDEN> 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 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) From: Po Lu <luangruo@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> Date: Mon, 24 Jan 2022 08:26:26 +0800 In-Reply-To: <25069.23134.887206.241281@HIDDEN> (Ian Jackson's message of "Sun, 23 Jan 2022 13:38:38 +0000") Message-ID: <87y236ou6l.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 4331 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Ian Jackson <ijackson@HIDDEN> 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?
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 18:31:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 13:31:14 2022
Received: from localhost ([127.0.0.1]:41240 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nBhdx-0004BT-Vm
for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 13:31:14 -0500
Received: from permutation-city.chiark.greenend.org.uk
([212.13.197.230]:59364 helo=chiark.greenend.org.uk ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ijackson@HIDDEN>) id 1nBhdu-0004BJ-Ry
for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 13:31:12 -0500
Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local
(return-path ijackson@HIDDEN)
id 1nBhdq-0007xq-Po; Sun, 23 Jan 2022 18:31:06 +0000
From: Ian Jackson <ijackson@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25069.40682.688423.883151@HIDDEN>
Date: Sun, 23 Jan 2022 18:31:06 +0000
To: Michael Albinus <michael.albinus@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
In-Reply-To: <877daqtnkw.fsf@HIDDEN>
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
<25068.23625.512978.147194@HIDDEN>
<87a6fntgfh.fsf@HIDDEN>
<25069.23134.887206.241281@HIDDEN>
<877daqtnkw.fsf@HIDDEN>
X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu)
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 53432
Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Hi. Thanks for your really helpful reply!
Michael Albinus writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]"):
> Ian Jackson <ijackson@HIDDEN> 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.
>
> I agree. But then, inotify (and the other file notification backends)
> shall inform that this happened. Either by an error signal, or by
> calling a handler.
I guess we probably want a "file notifications might have been missed"
callback. Having it be a callback like a normal file event callback
will probably make it easiest to deal with.
Another possibility would be simply to fire every file notification
event with a dummy set of information. But that would probably
involve changing a lot more code.
> For this, I have no opinion. However, I remember vaguely that Stefan
> said once that we shall not (mis-)use the keyboard buffer for incoming
> events, like from file notification or from D-Bus. Another mechanism is
> needed. This idea hasn't been implemented.
Hrm. I don't think I have an opinion about this. But I think the
design with a fixed size buffer, implying that input to the buffer
needs to be suspended and resumed, means that *every* piece of code
that might write into this buffer must also participate in the flow
control mechanism.
I don't think separating out the input buffers would remove that
requirement. Ie, the ability to cope correctly with a flood of events
(of whatever kind) will remain necessary.
> > 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.
>
> The following packages inject events via the keyboard buffer:
> dbusbind.c, gfilenotify.c, inotify.c, kqueue.c, w32notify.c. All of them
> could see a burst of incoming events. It isn't just an inotify problem.
Yes. How alarming. Well, this is a bigger problem.
From my personal point of view I have effort available to fix inotify
and kqueue, provided we can agree a way forward. I looked at kqueue.c
and it writes only file notification events to the buffer, so the same
"file notifications possibly missed" callback would suffice.
I don't think my emacs (--with-toolkit=lucid) participates in dbus,
glib, or w32notify. Of course whatever scheme we come up with ought
to be structured so as to work for those.
But I think the keyboard buffer suspend/resume, with
event-generating-code specific callbacks for suspend
("hold_keyboard_input" etc. calls in "kbd_buffer_store_buffered_event")
and resume (in "kbd_buffer_get_event") is not a terrible design.
I think every one of these other event sources ought to be able to
partake of this scheme (adding their own hooks like I proposed for
inotify) without undue difficulty.
The alternative would seem to be some kind of dynamic registration
system. As I say, splitting the event input buffer into "keyboard"
and "other things" doesn't seem like it would obviate the need for
this plubming.
> Yep. When the file notification backend reports a loss of event, the
> autorevert package might fall back to polling. Perhaps we could even
> raise another signal that things are back to normal, and packages like
> autorevert could switch back to file notification.
I was imagining a callback hook into the inotify code for "keyboard
buffer has become empty", which would check for "have we set the flag
for lost events". If the flag was set, it would drain the inotify fd,
make *one* "lost events" callback, and start reading the inotify fd
again.
The result would be that if any of the buffers overflowed, we would
stop processing inotify events altogether until emacs has caught up
with the user's keyboard input, and then (via the file notification
"maybe lost" callback, do one check on every file which we might want
to revert).
> > I definitely think we want to get (back) to the point where choosing
> > the keyboard buffer size can be done purely with respect to
> > performance considerations rather than worrying about lossage.
>
> As said above: perhaps it isn't the best idea to handle such events via
> the keyboard buffer.
Would it be OK to postpone splitting this out ? I don't think
splitting this up is necessary to fix these lost notifications.
> > 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.
>
> glib uses several native backends, like inotify or kqueue. It has also a
> backend which polls. However, I don't know whether it switches the
> backend during runtime.
I think I will let experts on glib, and the glib code in emacs, handle
this.
I guess if I'm fixing this for inotify, I should at least add a
comment next to kbd_buffer_store_event saying "you may not call this
unless you participate in the flow control protocol" and add FIXMEs to
the call sites that currently don't.
All of those use cases will have the practical consequences of these
bugs reduced by using a bigger buffer.
I guess the next thing I should do is go and read the file
notification lisp code to see how a "please do a one-off poll"
callback could be implemented.
Ian.
--
Ian Jackson <ijackson@HIDDEN> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 16:38:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 11:38:03 2022 Received: from localhost ([127.0.0.1]:41005 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBfsR-0004kG-8T for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 11:38:03 -0500 Received: from mout.gmx.net ([212.227.17.20]:50749) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1nBfsO-0004jR-G6 for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 11:38:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1642955872; bh=163Qmn4TwPVeFJ5sDDoxpd+Rn6myajKCDduDRR10Y2w=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date:In-Reply-To; b=M5ga4UOSODV/SJ3MZjeZqXdZxOttJHchAFD7E7Iee3AajjFCAowjeHudhJi7MnzMq /bYallbKcLmvFjY/o3lfrv/1hMQvc/SxbK7PAczgrVdcUXerj9YmZbo+qaRXEVVD07 jD1VzG/GApb8EmsD0et0ka0Qf0Z7pjTTKeKO74yg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.156.174]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MKsj7-1mqZgr1rQr-00LH2H; Sun, 23 Jan 2022 17:37:52 +0100 From: Michael Albinus <michael.albinus@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <87a6fntgfh.fsf@HIDDEN> <25069.23134.887206.241281@HIDDEN> Date: Sun, 23 Jan 2022 17:37:51 +0100 In-Reply-To: <25069.23134.887206.241281@HIDDEN> (Ian Jackson's message of "Sun, 23 Jan 2022 13:38:38 +0000") Message-ID: <877daqtnkw.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:hRS3NP0jhIEm/rp+W3LUK09+rfRa7p8jCdN+3yGUQZFtvndHGAJ l1qeRKl7aSIUA6VniEUNeFm95YAlu9wb+EivEm2McGtCnPEC4yWywjmaItoLPkOsT0o2tzZ WfC2F+K2irUeqkuSoGzE9c1DMB+Rml6Xdn3zAfb1rsuIXfKbn8hUQhoZjkfYS7xW4shm4n+ hm4Y8l9ZK/f7zOZdGkqNw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AJ5OMTJlezQ=:RkDq5y2ge/xMG2RV4bhY5V pw57839A4Z5DXYkJDAh1/QTc1y26Clj0V7cnnWMXvpKKDN7JrT+ahxiIiEa15h93eE3gSNzg6 x81qnIdgvxa/aa5hTbddllcWBzHGb2bBKnJ+/wgaZItA6Gfe6u74Jil8an272nm4h5Ek34xwm /MZ7lVnPw7hUU1PZAQC/xjvEcBTikwu0IcDAe4nl8U5y98TryBomFhIHg1Rn1fuEhwWHlJwJg fXaySbbBW2WAiMvVGK1/x0nXD/8sLKxkWeLHTDl+nDx6+lN0yMNGbBX6K+MEehgYxlbQtLSOo pQD8NVlAgySpDQ3TzFAXR00aWhALi98DdeUheabvP+BmXxvk3OKv5gh3bFFy7o7S6n3hYmHsK rG7pg4UAtICsVJV3b459K+ROwGHnLUGL9vXCCmeqWD++DDt9oq1jhsJm/bEZQ97HKEqOxZbXf pk/9k3XSUaTT2ETEPGitIeE+lOBcTPJfSz/aX8ilb2FEJNBbao1tCrKspyLUUl5gVTHEo7pLn 4xNGE/HY61SuXi+drr0+TzgbY176zx9ZezuVBeyq9hW2+lnpAl4NBv0qk/WkvR+hDd4/wrqs8 ul2qoePhs4/NBT8djMILNUc8DeIbULI9ZBVng9UA7CMlaKUAteYFwdEsMOJmm1lVUw2WJiF2q RKD2VD8dDfRrR+hAHinb5oHof3jTwSBxJ91xRt2+AkmHYWxAI5bNv4xWHe3I5gtXQYk0VyIoM YcwfpWM2WRVEuj1ml7Zr0bbxQOOEiq+3TM/OKHnbujiCnds5vnvgjOzOvrMH0yqsniEUj1DkG AxVEvp5gXnseF1MBNl3fO2it08ftwADetzu7bgWhcDnVEBLHUrSRYwbljsTLETXS/HTZmpRnj vTC8s2yc+PyqxHQC1zVBcP3KLs+CNrKkT17/EjjTccOxyLa6adYu6CpWdTeg4IBwt3erEp1Q3 vwIHgtpqyrn+YNzDOeXob4iAjjr9rctWcPOoMc/LVZrqU4GsMsVzwUfpu0XXh8U995y/2t2aG 7ijAxXxsKm+pPBQkbTGpmVx8AK4AB/u7B2isZKWiYA75R2KrBwXzPUK8sBlXTHOSdDVVlwyb+ DvishnyhsWsVi8= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53432 Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Ian Jackson <ijackson@HIDDEN> writes: Hi, > 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. I agree. But then, inotify (and the other file notification backends) shall inform that this happened. Either by an error signal, or by calling a handler. > 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. > > 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. For this, I have no opinion. However, I remember vaguely that Stefan said once that we shall not (mis-)use the keyboard buffer for incoming events, like from file notification or from D-Bus. Another mechanism is needed. This idea hasn't been implemented. > 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. The following packages inject events via the keyboard buffer: dbusbind.c, gfilenotify.c, inotify.c, kqueue.c, w32notify.c. All of them could see a burst of incoming events. It isn't just an inotify problem. > 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. Yep. When the file notification backend reports a loss of event, the autorevert package might fall back to polling. Perhaps we could even raise another signal that things are back to normal, and packages like autorevert could switch back to file notification. > It is true that the kernel's inotify system may sometimes drop events > because the buffer in the kernel filled up - but when that happens, it > sends a IN_Q_OVERFLOW event, with -1 for the associated fd. > I.e. rather than completely losing events, it collapses them into a > single "you missed some stuff" event. Yep, this another case (beside of keyboard buffer full) where a "file notification broken" signal is useful. > If we handled that notification, we could continue to use inotify and > fall back to a single scan through all the files, when we're told that > inotify was overloaded. I haven't looked at the auto-revert code, > but, is there a way we could invoke a "one-off" poll ? Don't know off-hand, but it shall be possible. However, if autorevert falls back to polling anyway, we get this for free. > 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. Agreed. > We would still probably want to have a significantly larger keyboard > buffer, at leat when inotify is enabled. 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. > > I definitely think we want to get (back) to the point where choosing > the keyboard buffer size can be done purely with respect to > performance considerations rather than worrying about lossage. As said above: perhaps it isn't the best idea to handle such events via the keyboard buffer. >> 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. > > 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. glib uses several native backends, like inotify or kqueue. It has also a backend which polls. However, I don't know whether it switches the backend during runtime. > Thanks, > Ian. Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 16:34:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 11:34:18 2022 Received: from localhost ([127.0.0.1]:40996 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBfoo-0004Xz-Hq for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 11:34:18 -0500 Received: from mout.gmx.net ([212.227.17.22]:60041) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1nBfom-0004XZ-Sa for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 11:34:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1642955648; bh=mSMikkgvT8f7fMOfGCX9c3sLnWD3m/HquuDjaGOXCbk=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date; b=MNQkR5SdoR40CHacVI8Gk5shUh+24OfTg53YOxE2LDtUcHBl88xcuPDLWPvVTtUvf c3XCthP+gyXzJSR3HkePdD0lv3gf69wS75+KQGP+DxGvgIZoAC0Mjl4W2/osEBhNxt 700vyAnaHIqDfoJ3hbJ3/jX7j2lXlHwsWYitCupI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gandalf.gmx.de ([213.220.156.174]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MGyxX-1n7b483jyF-00E3dQ; Sun, 23 Jan 2022 17:34:08 +0100 From: Michael Albinus <michael.albinus@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> <87fspfrv35.fsf@HIDDEN> <83y237knk8.fsf@HIDDEN> Date: Sun, 23 Jan 2022 17:34:06 +0100 Message-ID: <878rv6tnr5.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:+NK44eddokz1PWbqYseo1hF/OOGF1oJSZSGtV/h+Mtxwg97tB9l AbYZKaHeqzr0j0vHgh5y7Zsb5hN71qLBSCn+9lnc/QUW/KjWE/9RW0yMBRVEa+LfcorjoiS QMfqh1kCPDRCdZVSQFeLgSVabjYtBuJOxKCkVPNGcmv+nH9s8k5dRzgjCmGIL2dqoWgRlXX 5XhMu7oTRNEFaTAITC5pQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:QGro2u5ijw8=:KADyI4BcuF8FQmkKcFL5wy ZqwVu6smMV6FtwEVTWm6iSSUHiHL+JgXH+988qylsf4z/2zsZTI2sXQLHHvOskfrQjxZP8xrB Ar+iaWwVlrryqWfDnHNuMwJaRtH0yVxmc1GYDLzwWg+eCRKSla8qQpw2AKY0EVuOin3MBkpIH ztplIlIQciAoSDzAI9uOQiiL4Ve5BimhrE3D49he9jbcNKN8phYQzBRflxWbCAM3lOqFl+661 HIeHObEECuazaNmqyr90sf8b9Mj1OQNrvqfd4YsRr6VvCl7wJr/ejoeIgLB8G+erulxgEdmBW 6SOVDwE2qFbrN0bQeHN4Xi5UJsIdkrH1CO3WU0ZAbUO1dFxPEymn4Bfi7YNkma+BcwssCet4T P8QORhk426oBbTxBhV33FD7qh2I1q4OtJrR5ZTSCitGMuVMJ++J3PUowihA7Ha0BzT9FensWf zncfn8Yc/nCJs6OvptsMaHD+Z8WnF07IEefZPGI5su/3XNVsJp8omUUI480pdlYxYz7c9pw7s 0kYwEll+EjsLTASz3O3w9fCTT/trLfRE98Kqu6c6DIXxJOw73+DY8Bx3g6sn+ZUGQC9DzuPmN K/GqB+tA3WxczKdxqpS/o4iwHvOG4TJ2DeKv5Mu5QBfbPAZ63aPsOA+9zDObd/89Cws5xUzHZ 5PrUkX+2kMlUXNXAi5cA1/EelQ6O/V7z8KQJfjUDknonAdAaZ7Pefwh//LJxmTp9akdRACXW8 yeXXSgrH+bmYjeaje1wGLT2z9Wts9pdgNWGEunxmu27zzM2AT5vS6BBBMtEPAX1X1kcc0lEZj Np/n6P/MPjb1Gn2N7O9A8Z8yw/UQrCYBlF2RlkEERUoeBI1MlORszIh+iEFEzJO68d74gKrcR KL5feGYOzWCP9bCM1VceB4IkxydhUQd+KldPYE/SOUA5wTTWlANwfwx2hl7UoI64kxyofs6v7 PxIRqjaoLhqUWZI/WoX9qkuYC4LFbw3ZV/qUxksC2BKykVgeYUL5FZ1qft3+XOsIC1g+Eek+9 tuR2O7aJ1DgdNNxe0dVBPV41ht+ou5C1BVXo5H6cj9X1dKIF4SBBqTYsSpvRknAZZGJlAAaEl lt+f4CjoVDh1BE= X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 53432 Cc: Po Lu <luangruo@HIDDEN>, 53432 <at> debbugs.gnu.org, ijackson@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Eli Zaretskii <eliz@HIDDEN> writes: Hi, > The nil setting was due to kqueue specific problem. Michael fixed > that particular problem and therefore reverted the nil setting. Indeed. > However, my opinion is still the same: file-notifications are not > scalable, so people who use and abuse them globally do that to their > own cost. Not sure if it's worth forcing the notifications off, > though. Perhaps we should have a PROBLEMS entry about that. I believe we should improve event handling. When it is not possible to handle D-Bus events properly, and the native monitor detects this situation, it shall signal an error or call a handler. Packages monitoring files could react in case of. Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 13:38:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 08:38:45 2022
Received: from localhost ([127.0.0.1]:38904 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nBd4v-0001a7-DQ
for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 08:38:45 -0500
Received: from permutation-city.chiark.greenend.org.uk
([212.13.197.230]:33282 helo=chiark.greenend.org.uk ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ijackson@HIDDEN>) id 1nBd4t-0001Zw-Cc
for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 08:38:43 -0500
Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local
(return-path ijackson@HIDDEN)
id 1nBd4p-0006AK-T2; Sun, 23 Jan 2022 13:38:40 +0000
From: Ian Jackson <ijackson@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25069.23134.887206.241281@HIDDEN>
Date: Sun, 23 Jan 2022 13:38:38 +0000
To: Po Lu <luangruo@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
In-Reply-To: <87a6fntgfh.fsf@HIDDEN>
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
<25068.23625.512978.147194@HIDDEN>
<87a6fntgfh.fsf@HIDDEN>
X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu)
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 53432
Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
Po Lu writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]"):
> 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)
Good point. That means that losing the file notifications isn't
terrible. It's still not great, though. In fact now that you point
this out, I think this (lost file notifications resulting in this
prompt) has happened to me on more than one occasion. It made me
uneasy; I thought "why does it sometimes do this, is there something I
am doing wrong, or did I miskey?"
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.
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.
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.
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.
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.
It is true that the kernel's inotify system may sometimes drop events
because the buffer in the kernel filled up - but when that happens, it
sends a IN_Q_OVERFLOW event, with -1 for the associated fd.
I.e. rather than completely losing events, it collapses them into a
single "you missed some stuff" event.
If we handled that notification, we could continue to use inotify and
fall back to a single scan through all the files, when we're told that
inotify was overloaded. I haven't looked at the auto-revert code,
but, is there a way we could invoke a "one-off" poll ?
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 would still probably want to have a significantly larger keyboard
buffer, at leat when inotify is enabled. 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.
I definitely think we want to get (back) to the point where choosing
the keyboard buffer size can be done purely with respect to
performance considerations rather than worrying about lossage.
> > 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.
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.
If we can have some proper way of handling lost inotify events
(including IN_Q_OVERFLOW) then the inotify code could have a fixed
size buffer or a fixed limit on the amount it owuld read. For
performance reasons (see above) this ought to be reasonably large
(tens of kbytes I guess).
> 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.
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.
Po Lu writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages]"):
> 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.
I really regret (ab)using the word "abuse" in my original message.
I experienced actual lost keystrokes with emacs 26 in in my usual
configuration. I don't think I was doing anything unreasonable. The
build system of the project I was working on does do quite a lot of
file writing in a single directory but that is hardly so unusual.
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.
Thanks,
Ian.
--
Ian Jackson <ijackson@HIDDEN> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 05:51:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 23 00:51:25 2022 Received: from localhost ([127.0.0.1]:38412 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBVmf-0005Ff-8y for submit <at> debbugs.gnu.org; Sun, 23 Jan 2022 00:51:25 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nBVmc-0005FQ-Vy for 53432 <at> debbugs.gnu.org; Sun, 23 Jan 2022 00:51:24 -0500 Received: from [2001:470:142:3::e] (port=37280 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 <eliz@HIDDEN>) id 1nBVmM-0000Oe-C7; Sun, 23 Jan 2022 00:51:13 -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=AT8cOh6v34BrUJqI5pJsXGaGuVkvFYYqtipMFa1NJT4=; b=QKI2x2B2CAJP jxKiO6whD0w9iFJN/dvs1k/BrWPB/4N21i5NteuruJ13fEh4C3tcjkFQUYVITKSQR3l4poqj7fMPy 1OOB8FyY6sXU/szBL/ugqqdKH+IIEGIE4WJVzbhUjHO9TIUEFRsvUKWSBDCeCeGqBq7Ahs4QK6h+k QDRVfbGquMG/KfPCO4/rqEkSp6yO1rLHSy5h3wGCb8KvJLJPPF5Tv+g87dhtzejG5lBn6PNunFJJy L/MvredS4QyWq/kwQVOTChyC8Gs9hNeOZUc6kfvXSE9Jl/hrfxM0RpHwhv0muv5aSIAsjnyzg+H9h N7VMxlwqkWt3ayUkjb3csw==; Received: from [87.69.77.57] (port=2825 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nBVmK-00065N-8n; Sun, 23 Jan 2022 00:51:05 -0500 Date: Sun, 23 Jan 2022 07:50:47 +0200 Message-Id: <83y237knk8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Po Lu <luangruo@HIDDEN> In-Reply-To: <87fspfrv35.fsf@HIDDEN> (message from Po Lu on Sun, 23 Jan 2022 11:26:22 +0800) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> <87fspfrv35.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53432 Cc: 53432 <at> debbugs.gnu.org, ijackson@HIDDEN, dgutov@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Po Lu <luangruo@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, Ian Jackson > <ijackson@HIDDEN>, 53432 <at> debbugs.gnu.org > Date: Sun, 23 Jan 2022 11:26:22 +0800 > > Dmitry Gutov <dgutov@HIDDEN> writes: > > > Is it? There are only two references to auto-revert-use-notify in > > autorevert.el, and neither changes that var. > > > > Also see: > > > > etc/NEWS.25 > > 1108:*** 'auto-revert-use-notify' is set to nil in > > 'global-auto-revert-mode'. > > > > etc/NEWS.26 > > 1070:** 'auto-revert-use-notify' is set back to t in > > 'global-auto-revert-mode'. > > > > The latter coming with commit 484967796755051c4045cdcc26b0d3d129cc72ad. > > > > (Which was non-trivial to figure out because vc-annotate doesn't help > > with NEWS files because of rotation.) > > Hmm, maybe we should revert that commit, since file notifications are > definitely not scalable enough to support such functionality. > > Eli? The nil setting was due to kqueue specific problem. Michael fixed that particular problem and therefore reverted the nil setting. However, my opinion is still the same: file-notifications are not scalable, so people who use and abuse them globally do that to their own cost. Not sure if it's worth forcing the notifications off, though. Perhaps we should have a PROBLEMS entry about that.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 04:08:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 23:08:01 2022 Received: from localhost ([127.0.0.1]:38378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBUAb-0002hm-4W for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 23:08:01 -0500 Received: from mail-wr1-f47.google.com ([209.85.221.47]:44961) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nBUAZ-0002hX-5B for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 23:08:00 -0500 Received: by mail-wr1-f47.google.com with SMTP id k18so7298189wrg.11 for <53432 <at> debbugs.gnu.org>; Sat, 22 Jan 2022 20:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z1520ZAuc+vDNEJlqsJc8tDAN75k7k9LjGgcR9GuG1c=; b=ORUW9MutnwQsdk5M9r7zHFupm9ii+aAimqH9vxA+AHmJSIu20JflfsU9LEXb/e71wj v4rYRAdGwzmUWV2Tngx8PK/wMiSnsbn80H6fq1+wPOlLQWoECca/OdRXm8wE/a09pMlz gsO51HKKU3q260Cs21BaZDPiUmp6RNAWGFFuSVcoOLxcVKwgY4lxOxcuy6X+AxZ364P1 4mwg9ArhiP3O0Qfcb5DSF3XrfLuLpQNrGK6aUU01ooOyNo1Phi+MApZCd8TcjH4XB3Sy XdeSz/tO/4fTWiQHhgN7xv43RdqwmmIRIoyL760qT52BIjpfVvCz4IUtj8igF4MK4Sum Gu8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z1520ZAuc+vDNEJlqsJc8tDAN75k7k9LjGgcR9GuG1c=; b=6+3iHMlF5vBxD6uYKx25Ab5d41bcnRXMk2lTwFSrP4k+NZ8IHVPiJq/vy4Uz2EHKiT FsrlZGi3qcNONoWHoXSIuDLKQw37ILFHBadOMofQ7rOwITfqsJk6guH7IRc4It3d17m8 QXSN5EkCaeZmea2LHMNQi13sBugk8L2mfXgnGUUFBEEEqmhwTW4c8I3p2rW76NbirMLc MABbSmOQx2UmHLfLvkkvRNcL7CEDJ/dbwCXJNr1CQ0vS6yHLvx0kOY1vB8EqARrKhHSE +t8+l/uYHCGzMfJ69ySdDxm8cxRe7E29bHyihMFSxm5tDLkjn5U84BQtuiJbRDi6QdAN YzFQ== X-Gm-Message-State: AOAM530BAS58oz9WnbD07oEHJjx3MAW6NPYctP5lwM+OvSZ/RIW46AfG cxSQzuaUqJhqmll3ijB6c3Q= X-Google-Smtp-Source: ABdhPJzTV/PnrOyHTGUhCQa7TTfpxE2d9rvRPYaPbmq6Ubd1X9PTJnzjk4bwoghUciQkwjOfQc90pQ== X-Received: by 2002:a5d:55ce:: with SMTP id i14mr9679261wrw.224.1642910873392; Sat, 22 Jan 2022 20:07:53 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l15sm14424464wmh.6.2022.01.22.20.07.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 20:07:52 -0800 (PST) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] To: Po Lu <luangruo@HIDDEN> References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> <87fspfrv35.fsf@HIDDEN> <a27dc3d3-a3e8-988f-778b-195c659f7fad@HIDDEN> <87bl03ru1h.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <686be309-0508-651d-80c2-b009b40d4baf@HIDDEN> Date: Sun, 23 Jan 2022 06:07:51 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87bl03ru1h.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23.01.2022 05:48, Po Lu wrote: > Don't they also have problems with abuse of file notifications, such as > when a file is modified repeatedly in rapid succession? Apparently not insurmountable ones. Both https://github.com/parcel-bundler/watcher (which VS Code uses according to that change log entry) and https://facebook.github.io/watchman/ claim to work reliably and handle such issues. I'm not really a VS Code user to speak from personal experience, but given the size of their user base they should have kinks like that worked out already.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 03:49:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 22:49:16 2022 Received: from localhost ([127.0.0.1]:38370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBTsS-0002Ez-81 for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:49:16 -0500 Received: from sonic305-22.consmr.mail.ne1.yahoo.com ([66.163.185.148]:38856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nBTsQ-0002El-08 for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:49:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642909747; bh=smwE/sAKXjcu4TjmfzjIrH52gydw1ZlXvTsbqGQT+x4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=OTlrq7X9Oc7NhxQwXqUXYzflV/KVWs74IOAYBIRdEpkd2ZnioI32FxyOPsQocPI06vJ2HZz9pagwroMSsbgqIJ+T6OJaSY6B/xarWk5eOjSO5btA577fDNgaiWTJ+eXT4nemWB1bPGvIQCerXLCrZyobv40kmIEoOcVloSwFaaxLq4MAxAttGYPMMDFo50ewryTN19LE+FM3HMyPdBqNBztI9VwyBHK0Wd+gyBsf1OwBxpFtMYVdIN14rE7zYifuKxJbWTZINYlTNvAOxJuE9o5+r1rJx/o1iwaT85VNradQ4W512TEAwIoDRH2UXW68O0BlzV4M5gYD3L7yO+Ub3Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642909747; bh=Xb/4Q4ZgO2H0tRx4GMhd0Rs3JUEMCoG7R6m2SYHVIvF=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=TXjWZDSNf+OY2aPLLTnKmZXxP8cFvlIbR+XNzRudEB6tLA9Man2VtK4n0yQh+xYsxXcTE0NywW1EG3nGWCSoa7ZyG5eZrMdctQwNr9WjCo493z5c9M/efhlRsYqUoJpXCGJg2+Iq3kkNR6aCy3j1UyDxZ/mylvW7GgWmdB36LtztgTFi9nKiU2RBB1uGza8wVz93uk8zSbFCTkhUdfdRn/IVX8YdTnYHz3Y8u6ufcrVNlTiX0rreUDEjyjeG6XnmQshltmIarafWmJC6NjmqTgLsMiNnCg+mgGC4sHw4WlgFZwAw/ySVV5n71gLZuMuV5N8sbwduDI0oGhcaeVySYg== X-YMail-OSG: K7iZRXYVM1mPrgRre4CGhliqi3gAtuegPq8hdico6s2VTxesKnKOZIPNAl.ZgK_ Koz7wMiCclDdaiwcoz7_Oao3pk.Bk7v2ioUxHdZOLN3Kp9UxgEaknxdI_guoxAYrw85bxM7ZxRms o6Hmwp7goW4VC5VhieM0dlq6vyn84TYP61Lt734CUHXLPnhXR31O1hj4eXqi71MzKGh9oGPOmblj bG.XP23yKoXFyEK1kUhnyRtvgmJv6mr_df91HbPjbJH4B917lzS7vRTNmtv02rgdaZe_BsiD.2iH hLbN4tz6c1fLmQ7k5feQTWFudc3vNwp9PuNnp7MmN7bGGw3MQ_WwAVlSVdy0Tj.1LZq2n7PZ5gFE cPnk5kG6kYp.Fb3Bvvkhh2qnNKo4d8_niHRmfeG57o0uduBiR66xQ2FIQ3hPm_FMaGdTfTo51Dx1 MSwPG.h.OCDLxDabMFKIth7etrRAB._avjieN0m_zsnnQILIr_CsaAQWNYnt91bJFUpJKYERo8wr 3EUfKdK7TmStKEL59WojW_NGMeIEnbCUjIvFUuir609ikOsc1606mNNhbTN2XYLSKHDtmPs6Cqw3 rYn2OQ.BpvMwnd_EhHfn5.8PJq6T6z.wuXEcbg3ZvjJSEnwe0WkzYKtafE4DtLaXUECyj5zP1kJK B9ppCR45VoqJcN5iKEHPbX2r1ilqkFqTk5e2.0muXKzw0UG4GB7l0PJTZMuEZCoo1LuGThsFStvT 0cf5fdj97r5h3qW.6yXkQTnvB6EH2G551Ek_ud4IIrm5tJ22Vju28z5Nf7RdmvtD5A6eaYJRsKMF xn_NgMHV_DPmx254fGFLbPvMs2vDqtwGfBhllVT4_axwpvzlPlELyUqc8iPWrKwmrd58wGabdULZ 9msH5eeYQ6GQoA2M_O0CAwWhBZQtYSlOFXC3VgPi78urOAJuTQWAr9giKY3IrD.7B4uBH40UwapG 6TPOJ5AdzYCwMgcMdRaOgUwFj19uDFjW_eqSlv6MoOhJXl11S1..4kJCz6LEFaxknmk2kFAM.HXI uyMEih4DugzcMPpBN3_tLdRGu4bsvkC8l3EFsiHpUJyPsuemD94Cf.eSTsaj1pUNG6F554HlaGET cfPrECjJG.ZA4u40CN5zY3KbFirih.8lB9XiKSrJU.VRioV1Qg6pXEx6tM5mrEOhwA_knaBQVVUR nHFOcHlhIMf12L2BBizK1W1dE5mmQY_5fTyZpziNNMX1IuJ6_Hqlv3.hHOsxCVZbiRivqZKElyUS g62rdPrT2PkvF_2Kk3GJNfk73caHFwfdlgsKw4vqSH1m2koQTd4Ah5iRokoTIbJBr3YnnCQOOspb YruteH7enogXm1UQYM70Xs527LqjLkNqIVmC5Wj.NwikYK.AVivPFRyH_f8e8BSyMqOARG4U2CSe ZFWsQXO4eGB6cIiKKuTObYy_aNIM4b772NnYGEbIRQ.qkqlUJUhm715VYDbLrueYzs6wAyY0NjHe sVIsID38iy1Uh50O33kEtrropayMVN5bD.MAe6OwTrLC0DAetCBjdnNI5u3OcmYIURuAenzNkAQm AtEDg9..V9w8OfspnHAw9dl9u1wy9d0oom8SrxBQ7meLRm1hsK4.RQc1epA_AKHA66oZ2bEbHpDz jA6iwWNKJeHoNxO8gsFzsDqalI9bfU3Gxfd0ILCpFA0HpbzG33RqW6tGZahlm8F9E4gAbYLOCcJy gy6U6dSV_y9S8UkeRU9kq0VTQvwSS7OE4Jt3srvyqImbk8sUDgWMrZY_0ta1i1Zap5KwU0UVqiQm T8TSLSGonszb2e2j._qKTewP1EX0a_AIQTTFhWY9DeSyu8AeQH05ilKC532GLzl8iChtuJfK9shB ahJUZqWKe4GXvY8TIIgtmKwDaSN4MiGmwflCrn9aTa_988DtGX3RtJI2.AI8a1t5lMuijRRdnOLL .6hP_DJBR04j2eV32nXS7caLCzjfqKLgq6QDhy6M9NRQBepToJX41ER8kvL.9x6F0eLucbJtM0Xh az0yAKcP493GULQXJx5kouhChrp84OGmAmOnpo6RfdPVgLogTYc1Mpocq_.gJQRJviyYCs2cklWb MHs3PhYHZ.pN7lsuF8veZ._nuzcv18LYLAvI46ltio5bjRF_Hlgc4en9SdyhmnR3XkOjkBO5_DhD IFniFP.UuZLC418Kz2KV8lamDrmZbaHc6PMDWQyqxje.ZQspAqGMUIrSu42WQB8xsAqntce2oGMN o3YMcOJMJxWmmywxqlmOpVa22RwjEJPRL9ol26IibZ3WQRYPzDwXnoFLC X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sun, 23 Jan 2022 03:49:07 +0000 Received: by kubenode514.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID e9ddf51a9c468f7551ac057805ae042f; Sun, 23 Jan 2022 03:49:02 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> <87fspfrv35.fsf@HIDDEN> <a27dc3d3-a3e8-988f-778b-195c659f7fad@HIDDEN> Date: Sun, 23 Jan 2022 11:48:58 +0800 In-Reply-To: <a27dc3d3-a3e8-988f-778b-195c659f7fad@HIDDEN> (Dmitry Gutov's message of "Sun, 23 Jan 2022 05:36:06 +0200") Message-ID: <87bl03ru1h.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 226 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > VS Code et al. seem to disagree, though (*). Don't they also have problems with abuse of file notifications, such as when a file is modified repeatedly in rapid succession? Thanks.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 03:36:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 22:36:16 2022 Received: from localhost ([127.0.0.1]:38360 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBTfr-00086s-RM for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:36:16 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:39489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nBTfq-00086f-Jq for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:36:15 -0500 Received: by mail-wr1-f53.google.com with SMTP id az25so7228208wrb.6 for <53432 <at> debbugs.gnu.org>; Sat, 22 Jan 2022 19:36:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=FCwJNcp8e8m1bbnnvHZXgox8LoaAX4qmjMnIHS6ks9w=; b=TI0b1KEZcre5NBVk4pTHa3jnYzBa2yl82cpR8MjAo3HObW+LG0erIehyh47PberQ8Y TGoVvCkJVfqYAFH/SBrrXAVjtyGAFa/y+BAPGlORQhVUj4I2NWP1TWpAWxiQ0nyoVBpX KvmeJ/YV0/oQHLuR366fhy6BCku1HgYvQRycOvdkP05SBgoR2FnfTkNLl614nSBmVgd5 Gch2GqGojpDdAVWMUqPn5bsvn+W4S3YTOgysdZGDmvYVr4pfDnd2ufomxe/6ddZkbvhM O06ricWMuwJGmPballJXtVm4ffxa2R4E+RbT/TvC4TwmQFMgK6gnuZKckrjEiMOtC2l3 FfrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=FCwJNcp8e8m1bbnnvHZXgox8LoaAX4qmjMnIHS6ks9w=; b=MnboEpi7EzEMr712ESz/kxc8Kui6uGe2xyOPS5gIzNH0DzQ6o6wRRns0va1zEo4oMV kRvUmJrldhKwwn9TDUv+sQ8ZaAjNqh/dL3tWUGTBzWKi4jRlCl+Gf4sxNCBeXUJKeJQL +J3KZgS/TbwUDAjVxIuy0YcIJCBact55cKWNY6DptgMr5qE8UObESiVwybx7AZRoraNf 0CN78mdn9S3YfNFafpejmkmGhFOoPs6T5kKmSWkn9QXMgXWnl4/FxpIQ/30eX6MhH8S2 mG35mck/AZt/pUPpa4nsDNi5P3EIYVZYat1jp7p05xXeHwfQFJlfn/+0hhy5gowY5LsL NkXA== X-Gm-Message-State: AOAM530J1KZKf7gjnMAnFhnnaGjs29nh2KcE2V8kSDQMyLA1qraPfl9J yWCUOdsqnkIp5QfloY2uDvw= X-Google-Smtp-Source: ABdhPJxrytWP8vYxsitT0HlVLoygB/kIW9FzMGNhGgk5dnlPfN/SB978ikyHu56f6tMuywwGMyMXxw== X-Received: by 2002:a5d:598d:: with SMTP id n13mr5679515wri.165.1642908968269; Sat, 22 Jan 2022 19:36:08 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k37sm16095487wms.0.2022.01.22.19.36.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 19:36:07 -0800 (PST) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] To: Po Lu <luangruo@HIDDEN> References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> <87fspfrv35.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <a27dc3d3-a3e8-988f-778b-195c659f7fad@HIDDEN> Date: Sun, 23 Jan 2022 05:36:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87fspfrv35.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23.01.2022 05:26, Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote: > Hmm, maybe we should revert that commit, since file notifications are > definitely not scalable enough to support such functionality. VS Code et al. seem to disagree, though (*). But it does sound like you want to discuss this issue with Michael, at least. (*) These pages might be of interest: https://stackoverflow.com/questions/50901127/vsc-unable-to-watch-for-file-changes-in-this-large-workspace-weird https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_62.md#file-watching-changes
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 03:26:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 22:26:42 2022 Received: from localhost ([127.0.0.1]:38348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBTWc-0007rA-JH for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:26:42 -0500 Received: from sonic306-22.consmr.mail.ne1.yahoo.com ([66.163.189.84]:42201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nBTWa-0007qx-Tm for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:26:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642908394; bh=1ePcXbWZhtzFfJSPQGpJnuULSNLgi60aanb2d31lwfI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=eN2WijAo3EXsvX+/y8Jv7iWeVU7L3NZ3mDEqDzOQk/njYd9Kb/+I4jKP4MQ8wDcSNnyAGfnJCInwiyeemvQhd67liEvbzoqRuIPeqTNtJ6+FDIL81NcBSnRU/vY2sGa5XFkbVuXeC/0NCt5BEOLyngqpD8SrYQ6i2qFIEsyczBg0+h0X+uThfovkxk5Pun2etezRhIYbxlPEnyTeUZth9Zck8mGDaN19hKdDoInjjkS+B+WaLcqFYr8YA8Dnl+g//xgd4QppfNat53CRkoh7HkiWlU4yEsOO0sruFZzdDw1sulccaggkDPmwbsgdCUXycR/HG9kYMPmxPUPFtJJWQw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642908394; bh=Oe8SIhYpXE0H4jvqbCEhTf0eP8q68vOEdAmn7Ezejo2=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=IlC9uDYeLxY3aWrmlitmPpPrRghgn4yko8GjnvqSuQ959Gqm8ZtWs+3AHcZQiwjZN1PYsY0h7BszwAup6/UeSxDIP0ftOG0LxoV1+ITH9fyJDrphbCYjgB1Mug4zkSVTjUWlpWgiWFHMD0uYsK31PwXNykKn8C6j4yzvBgR3UbiRvAy9QS2/ZWFkDjrtgyqocX+8iikPSh8qC3sddElop91cz8urOmjz5r6A6ItpsCmM8+0pk/ZcqV2AboCjic7DZOhurHchdD1afa/8GDEF/wCVUuqqaK8aeTomstcBCDhk9Rd4fBMKfJNsc2d8/XnjP9/wug6crTAcLb2ps+aXPQ== X-YMail-OSG: iSqBOj8VM1ne0YbqY_Ptiybb2G7ZAZKBsi1yKTAw.0VAkD4t1KjanHl.GN.KU4h UuhxI5QdvBqKCjiCivqRFLGnSrmnSkAss9lD9lkEX7ZDMqjEOWH29ljxk6Sxt2L32fk5PZZNJIp_ FeqBeKxoPnxeEBwirHMD4z1UWxZd4VjVrlE3RnhH7aTqlzMgEJDLbFlGVjTzR4WDUKZBmPBaACf0 v_N78BRwTFnATpya90tey.oHx0ngeqia_pxU0entd8KzrRJ8DP01emW5a1TwEUjoXEXQaQjwK6xq SuqxJyzNcX2a2xWewfO3vVVkoJOp_m1Zr6q3vr2oBgA5KZd2TTlksP7MVhh.4cj0_7nOAzM0Tae3 IbB4hujrp9gIZHrhZHcQ_wp6Xeu41er9Z8k8.Yz7Y.NhUvpMeF0kHN4ghhiuSsMojamue3tAT_6X WvE.UZz8Tv87iM0AdGOYqpu9QClOBLBHhRxFBISPDmR1GoJmNw3stM3wXvO_pZEcCarN3kzwBSwW UU_9YYT5RcPSktwz4bcEvFZkeB0EeulM77Fen2FnxAgCozJMepwJBxJSRzhKyW1kO7Ja8vcXrFGb rG2L7IUTvSCVgQRbyXzE3NfgybdVXIyfaFth68Ks3pWUSm0Q18K4pcx6IyvrDeSzTSSzJ9XEtQrx QjOKqWP1AuHsK8qkj.TmAe2Mz.CbfmINgGl.z8NKbTzbht5N2N1i3.ftJy.dfRcVDrnQb_i0ZzHp h.CFCQ1aTbcsJn8202WG0dPtxH982lZS3rSX.5PlRNZ5oGl5IwV4f4YXEsQ2SwURHqVEAe6SR4AY MctIyvJnbaeEvFwO9f5TOl9vykbBJwemVw8JobNQpvGpS_D7hNa9Tfdb6IM52KdeJSrulDEgf6fQ p92wl8MR7vJg0nDww8en2miS2DZHkceXUJ5RXCBY0OOVovQ65j8fFTNi3isX3ZU2_oIem63l1iAz y6saHUyXj0Lduv7QOT5coAAz.seAFWUPiyVrC9_SpLvCUg5.EFwxw8x_C2ENVJdlLZd_Nw1mf85q 52A2G6Oyv6mri1mw6X8XxrhoSGltpkJCMpsHTFRazSc65u8a7eNThpDZgUCOMhH3Hi_T_tn9F7Qn UiPNKlK6fWZqmjx.nntWwHlAZ3Wy7ycmpdhleShLgS0OSNSUnWtNNlJ2dt33eiNvcBexnKAgfqYx adgEq4qv8WLcm7iRjJ9iugLRpcUTq6VXWZTx74XrXS3XCYN9mgpWQRy6_gF5Zi5mSrB8C0MFLq2u GCCCgRuX3TR5zshB5rUv0nwdIge0wkRl7zJPb_4WNVt2zqt9OIabscKGE4hn.lRXg4v7Vh1QUTZk 3yDGi0oVuBvpYvD6AZm2GCbFviSuo39flTIUf9sUIAgE8qt44gZR9EB9KKHKRC80spEhEDONHsvd XQzRrOprXgGVWu7lW0zBRLJBJEWLCzDq9ibCh_5xLyw0BfUvE8qF0A3IhDVpIZS5lWwRWMiZoeep l0nYUScdRYtaMRw.PBrNVq6gHMhEljkH0pNMtlNQez.PHG4kwEdxL7idaOp944VQaqL8LdW6AfAe TQrrn3CZY_IV0e8XsBL260zNFtDg7II98SzhHABharutpzDnuBp9l2p_ywyv9gLP0gH5299RBeFn D7nIFoY7QOku8qjLI7UjCymzlJ_rfmSfFyya3bzZaWwrxb8bBOFzhpZthUKCGDegHrADzNKNADHm OcS9LS3aVoUMsFrgE9o6tnM1X.WXmkPdk7hcqEj0L9AQASF9GB4HrlEUJ6WOfhGYd2gTNC4i_xyZ 3hcPk7hO8juse.KBxE6tI.1kmXmPCXrT5eISv8Gli5MdfuDMmKAC.6zPiPliJptYXNrb.Ok_5O.n 8YOEsfL3bdH11mbUXB6Jvr94WX9emUQzieuKVktoZdjHQN9NWNYM8iel9yarDtZCX9MwZtlzG7xn 62OTHA6I3yUK2TFHcfZMsTRW.ITfn0PQ92DT.pLH4MVpZWgDPlixdzjrWUBveEtDXwHukEjO4Imn mcGIGKOjvkhB78gvUnPER9WZ2pK9p.uWApxvts8e3aASJK.feNTs.zPc3bEkEy03D8t631qsYiV2 KX9G1dkV9e8u.aXKNfv8DkbRmxoOU7uqInhj.2eNmAmprvps_gRa9osV.ko2xa8gfmRLpYsHyUpS bQROg8uf87XOwaiZgaZXnr3sLnLX_9BUMqxxD4szr3hOCiYI0Cekx7NHVC0XRjo_PBFjHDXwYajC 4TgWtBoojeOsRkGf9RtW3LpDFgg4zp1mURmYb2EbTc9Z7bGcLFRLFGN_wfg-- X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sun, 23 Jan 2022 03:26:34 +0000 Received: by kubenode504.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 0beaecbc11ab990cfe621dc1c0606c3e; Sun, 23 Jan 2022 03:26:29 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> Date: Sun, 23 Jan 2022 11:26:22 +0800 In-Reply-To: <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> (Dmitry Gutov's message of "Sun, 23 Jan 2022 05:23:40 +0200") Message-ID: <87fspfrv35.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 697 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > Is it? There are only two references to auto-revert-use-notify in > autorevert.el, and neither changes that var. > > Also see: > > etc/NEWS.25 > 1108:*** 'auto-revert-use-notify' is set to nil in > 'global-auto-revert-mode'. > > etc/NEWS.26 > 1070:** 'auto-revert-use-notify' is set back to t in > 'global-auto-revert-mode'. > > The latter coming with commit 484967796755051c4045cdcc26b0d3d129cc72ad. > > (Which was non-trivial to figure out because vc-annotate doesn't help > with NEWS files because of rotation.) Hmm, maybe we should revert that commit, since file notifications are definitely not scalable enough to support such functionality. Eli?
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 03:23:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 22:23:50 2022 Received: from localhost ([127.0.0.1]:38335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBTTq-0007mN-Gm for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:23:50 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:37479) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nBTTo-0007m5-Tb for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 22:23:49 -0500 Received: by mail-wr1-f53.google.com with SMTP id ba4so7181222wrb.4 for <53432 <at> debbugs.gnu.org>; Sat, 22 Jan 2022 19:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z9znsE2Kitq/itHKGjiewf1IdLWVk7V7ZrWTgoo1US8=; b=EiJGM++d9MH1hNTLPbVW+EYPTXicCKrTD+zNg/YV+sqF9msSy9ysiM2uT159fG+aIN z9Bszt0k1ee4ibKPngxLy0FpMfXY37B8qq1ULLoawDILoBIWj+mG3jaWbe3JTz1+Fj8I b1vfFadE9ZDa51TjMNkt4hN/6Y0MNjRFntbXlHfoF65MKWrWCJG0qeivJ60BkahN79uK fjVkiSRasyRi6KB7pKYwY4CWFGma4wK1gbbg/ybmKAh0sFwys+iHydRYZqfL8PRkipmi hOpVEF15Pc97117sp6xUOiTmYX3bwJ2AZlu7jpP3Q/kF/TBLvEcePzB/20+zXIq5uATE kbgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z9znsE2Kitq/itHKGjiewf1IdLWVk7V7ZrWTgoo1US8=; b=XrIgRyzNvZAz97bpiCVuBEkPuT5Em+zO04UbuHkWvW+Jdqfw+2eITN61iACe3pVtnC 7ro0qhdAzhHFJnw5rvLagn21+skqos5xoNqqn0Ng73ThgQBQQkbqyZtNRn7h9csAkP5+ 3kklEBgIlYUoPTmcWBueN0x2vuCRdpxcs4MG7xJBS9D7Iqmh6R358yqhFm3Fzat4kvq4 P2Rpk1TxQ3+LKfspLyoycrZBT5hhW6srVQ7ncAMF3DjhuM8ml7bZvJ11cveODF8q8ib8 nLRzHPLVDhXx4D3CbSEjFSd9dv0AM6C7PLDipx4MNoidBRSu+dHmjRGzmkp4tXpYKx9B 8mZA== X-Gm-Message-State: AOAM530gvJQEQuKQPfYQ8e90fPHOUKUPm8mWVbXQ8UsfhQbJahE+E4Pg iMm+ReBcseO7s0JQ5yLXUWuP993B1x0= X-Google-Smtp-Source: ABdhPJzfT5gc0Fci25LfJNY9I4sm7cakVmlV42/8xKQVpQon2BIqaEd29Fv6gCijFLFcd7sdhbGipQ== X-Received: by 2002:a5d:4291:: with SMTP id k17mr1270207wrq.328.1642908222090; Sat, 22 Jan 2022 19:23:42 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l13sm16090400wmq.22.2022.01.22.19.23.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 19:23:41 -0800 (PST) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] To: Po Lu <luangruo@HIDDEN> References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> <87k0errwl6.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <9a0d361b-b052-f613-8279-624c2c8b16be@HIDDEN> Date: Sun, 23 Jan 2022 05:23:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87k0errwl6.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23.01.2022 04:53, Po Lu wrote: > I don't know, but that (and scalability issues) is why > `auto-revert-use-notify' is set to nil when the global mode is enabled. > See bug#22814. Is it? There are only two references to auto-revert-use-notify in autorevert.el, and neither changes that var. Also see: etc/NEWS.25 1108:*** 'auto-revert-use-notify' is set to nil in 'global-auto-revert-mode'. etc/NEWS.26 1070:** 'auto-revert-use-notify' is set back to t in 'global-auto-revert-mode'. The latter coming with commit 484967796755051c4045cdcc26b0d3d129cc72ad. (Which was non-trivial to figure out because vc-annotate doesn't help with NEWS files because of rotation.)
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 02:54:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 21:54:20 2022 Received: from localhost ([127.0.0.1]:38325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBT1H-00074E-PU for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:54:19 -0500 Received: from sonic316-21.consmr.mail.ne1.yahoo.com ([66.163.187.147]:32808) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nBT1F-000741-63 for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:54:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642906451; bh=UwGzpKOL6LR4U75BUOfDMG/j538T8J8/DJA/GnYbZuA=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=KBPvTJC+CyFqtNgGYk98Kua+4zFMq+WROn51OKHelue+agSkwz5NzFJMxUXqLldfxKR+lrAR0CWafpNTwI4JZ7+n0mF6epu1hbbuwfo8haMKGVbbUD+mLgf9ZCeCYN+iTKYea/PuHZBiZkgTh+NWTFNEcrYBEQLwpc3Iwq2GHXMWmsw/XMdydaxMVptEJU1VfoPeeGVhbZSn09G+1ALyxjAJb17KaqLkC+3ZcJ4fuLxHV3x5LDrhAug5rv/Lw9Rn7ubmdXjlmUNrcfDOEovAFZkC6c0oT8dLxYwOY29pZekqGcQKCr0BruTXcdzTkBrYvLf75fDBRSVTuDbTjKMA4A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642906451; bh=9og92dBtbEXlxSgSCuoiA385EqSMeWOBKG/E7TIVNqi=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=mFBZVVdCwq0bi8u6i9BIjRvAwkg8qb0YXF3n5WNaiThsoTg0M8zZ/JxRPyfiGTGPNZe4sZh2Z45R5U8xSY/rPj4urOx1LN7O3Fx0+6mlpUzw/7//ocozn+LoAxTbH3cmA89V129lZzDpsZmnvVG0bvctWCCB5IPl4pnfguCiTNgwp3huN4N7kgA2FbByUSV3bcr5t9Gw0W7vbdFxJXhmtJVUw8rNev2YZ/L0/NdZcpkS64xDfX6ucu/68vsVIz7EXYey181lc3OVte9v25H7Sj2XSmwZwCJVVnZfJAyQCLTVnLoIPIZFNKFFk1AVwS2CRGcMa0yIkgDjnuVir2Ztig== X-YMail-OSG: M.OPITsVM1mvNr8BSe3cqreuFHvhL6Bti1_DVh6jJdtf.0sVIXhgTvt0jbwaHmM s9FliQlGJv30FYuXb2ZJWZRJAjlU2_ixvpL1lqVKsG_ASh.Qw0FCrVEZ67IJ7PEV.blMb5LuLlwk 0Ay9ZiTk43RQeMGdwnk9PlDRz8BLvEHLYBSHEPcvLUHG9whqGJkiiXhPYw2YNObRjbpLnxGM68Jl vC77NBApzTabuMnEoMmJMM7xXJCgV1LrIrJ07Ch9WR0rykzh_r90O11mUHQI.g_yePXjfz4phUXn 2oE71AD5_MktC9KS_ssZzeZ3VeZn_CHrd_8HtAwmC1L7L1VjmtuS86cYPb8FpM5QwqyL5huINA72 k5L7tWwbFwOJ.JQuTEk_EtovraTWEYVVkv0GOkngNEXi8LSQeWRyIeI1gDEecXIeoPtpf8Wch0Jb Q13O1_Ot.OktyZjoNK4CWnxTVHqGlG0ayuGs7n2BT3MtIkB4cMphXJYwh56jY4Q2jw.s9lYpeWZD cxMSHXnFYqE0XAPCXtxG9Ws2._.LmOUaXTx0XhCnuJn.ytoatfRU_OZ62pwo3Vyd1te7GJv.FUog ec6HKmViELQkB2.Xg3glduuorUcdmuW81Eu3i1a9CYT7avcteyEBr9J_uFRwmufcCLhwG.H_0W1P Wy1FltaPgqRq_ZmjXRMhM_R4xJ_gxADWu7dd5M4CcrRH4PbOD78T7UQM3UIAMSj0SCemmaSO9g6g GXQNo4h_3rpdinPfGDG5h_Nwk6J3FeGCGgcmigH0tiJe9ly32bPV9G9NBE4tCl_RkU9eLMsdn0h1 LaogDdleFy6sIBVrgDTs0i4FpQXvuhZYjlao8Pzt1VC8u.DNDDMmKThArQPGuCMvadpc.Az_bGp8 7hkh9WpGkS99M6byVdVEnXg6NczP0UFCA41z5w8IzzSC1tSqN20NQC964iTsWcXZcCq4hnjNfPJy PGHABTx4A7w4gOid2rg2HivmI0VWvURuGFNBcRpObmeU5Ct1dNsqyGwNJb1fQ7akUNjPjKVg2zS7 6OWmnVS9607BWAMr6s5fTR38AIbvmS1Joq.mo8NFbZRZZ23nu0I8G7jleXxoA9W0MvIVVPvwPF0Q fnnffJ34LkIzPoNl81l.0WStWXwkzSaux8P2FlPyBXJFODXZYHzXfvLGHtNHlRX1sbVhIiA5pfe5 ppvn0.To0Tg_QZkr.fD_nFIdz3UOmtBpnCO8WIgerLFFZWiXHOSuGXdraFR1X4uY_ofthjMZrEyt x505009KDrrofhFFxREs32OR8u.B8i81piG8s1g3ltQXK6IEJu1ar1R7mqnUWbBTEAf1ZJ5DnA0I htm59V7Uk6JaHcwQQxRAmkZ_ls29L7ItHYugpTpUwMX8.OZE6_gkWCtPDztbrMvThUi6_Jv3H.GV P__DoTK0dAI7O4d6_qL8FPcnP6Ivd34HQcJ48OZoML49kIHinNhbAgd6PHY2_n3jwb7mvEOtMYdm w60RkQuPUFOUfGYMq.T0nivl6VfHkx8bTWMsG5_E8nZ_BqeCap3l5q4oR5YZ1wo7bhMitHaiU.w7 t0RD5oo4QeXAG.HET7PaTEt7qa_2mgaraVkuIOWrmRUnTLIqLpE1ICotVtb7rOoCmYxNeXFyl8RK bi5cJ0wmsA.TgKvSCmI7w6mGw.eoLYWCey3Tqh4HOOfF8AJRFIwaiwqzaN1ynncQuYo1xugnFmhJ DXHP5Y3Z8kAtt9EZYZKDKVo.SpOyjOgZ.AyTCUqhTOV4cj3PH97HnO6qSK5CybOwl5WlH8xCUhJ8 oZ1oaMyquyKf9Egbvx3_Be9qax.aEYOIeiCl9ExY5.wNqF7YPa4QD7W4GDzzsjRaljGNktl05521 uyFUSorwqtji8bJPKDF9hPj76PSMsYJny4ZdzwvqYlP.PqJRS_ExIz83c6H1zUHkHiMIuj6XPkiK CDWplKFpYikOaFmre4WoJWlLebw4VJ94WjWrxCL8i_gkUlvdV3610RekRhb1CKpCiI1UwK95B3rG MlQ8H5sN2zp9_HEfkElejLtNDUvDx7.zE_eAyf7XKUpC9W3aAXOLNdhg9k7z_SaSHg2bvbzyl4Gk t5gsmZoDbbmjwKoSQVuWRZrgVLEYMNtHHmFgyzyDyycYgPQZxVwd61hUjA6dk0LwVtFDweoM9UDN vSTI9O9PLVz1Dequ5w20YxPi2Z1.vpaZuh.kOhVWgTLrVIDWCyK_CelFXrSMmR.jBHtye_g8yPX1 jAnUi0SFw_PlhuS3BudDQYkK2D7RjXYPowJZijSmxJikoVs.bwPBMu0oO X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sun, 23 Jan 2022 02:54:11 +0000 Received: by kubenode501.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 254f0355a3e06c8a766f3b565bd379f1; Sun, 23 Jan 2022 02:54:06 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> Date: Sun, 23 Jan 2022 10:53:57 +0800 In-Reply-To: <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> (Dmitry Gutov's message of "Sun, 23 Jan 2022 04:49:32 +0200") Message-ID: <87k0errwl6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 231 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > Why would it be enabled more often? I don't know, but that (and scalability issues) is why `auto-revert-use-notify' is set to nil when the global mode is enabled. See bug#22814. Thanks.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 02:49:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 21:49:45 2022 Received: from localhost ([127.0.0.1]:38315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBSwr-0006x3-0j for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:49:45 -0500 Received: from mail-wm1-f53.google.com ([209.85.128.53]:40710) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nBSwm-0006wn-E6 for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:49:44 -0500 Received: by mail-wm1-f53.google.com with SMTP id r132-20020a1c448a000000b0034e043aaac7so7907383wma.5 for <53432 <at> debbugs.gnu.org>; Sat, 22 Jan 2022 18:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=SeMgWgRYKg/qwZ49KzdGGPYRSzoaHgwiux+P6rkmI7s=; b=a6QgMbIVHH1EIEM/ezldn1txq9RZ541zbnOQQeNv9Ds/VxL9v8YRMY8iAZGGjSNaEs wws8yWiOy6NlFBEpYM/jrTNpubQzYRv5s/bMDXdOBIVF01AgGHUhHT2s2oGePUrQOlOX F0ww7AbI/puazsK8jXNE/4dvzQT3NI70ye54XQdfgIgJBefPzbbB1AMCyoX10KELdK+0 4BKXvG8xU6tChgYrse2rDuy6dtFqon7U+GLnQqqLpRF0i6T72Wl+9VSxTWSAC0PjB803 zMoo+GRbGiEk1rsB7PKoVMeDIVB4qRNWeY7rye1omex7F8irH8tgY10s7Lzq4XigPvpI T2pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=SeMgWgRYKg/qwZ49KzdGGPYRSzoaHgwiux+P6rkmI7s=; b=bY7d4czX3/71a1JECFT7+kWwNMxhfsEV9mbNpJ0faBwBhGG12uMp4yVCC7WTXvDbGi 3z/OxWP+eggPB/EqeweBzEMt5U8cu1LpwEwxITYt5dtoJRxE9Rgm3hJ95p0XM6i7/D0V nZXK4T90rP8XAWG3S2QFhVw+3mhcNJfmolPDOSK27mmVwajOWGXWGS4Bn5iCMRakxKKw 2UmmbiOfJHpYD4mmlOv1wfsSIeiPAL1MPcLjvVLfMw2IdtqCVl5A8h5bmKlUesh6dIDH ixwRBJLohKfaQdiLxD1k/Hao1HZfSAq2ZCaie1gxo2c300q6yTJjOJjqq9g0KiAB8VFl LHmA== X-Gm-Message-State: AOAM533rf6Z7Fm2SnHZZbrePcXrD7AzPgGv4JUVpHkvhzmwzxGgpfIuB LrPIdJBb+f9Mgql/DC+IvgXdwv5PPKw= X-Google-Smtp-Source: ABdhPJyjxFhOco0rMPm3UQXoIzhfjYSQBZrmVKIBHh4t00HDH9aSrOCW8+ztVU+6ZSZ6bMHFS/q0LQ== X-Received: by 2002:a05:600c:3502:: with SMTP id h2mr6409153wmq.143.1642906174438; Sat, 22 Jan 2022 18:49:34 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r12sm10216295wrw.73.2022.01.22.18.49.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 18:49:34 -0800 (PST) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] To: Po Lu <luangruo@HIDDEN> References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> <87o843rwwk.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <f768cb31-56cc-3beb-a37e-6e0778968798@HIDDEN> Date: Sun, 23 Jan 2022 04:49:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <87o843rwwk.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 23.01.2022 04:47, Po Lu wrote: > Dmitry Gutov<dgutov@HIDDEN> writes: > >> If it was really our recommendation, I think we'd set >> auto-revert-use-notify to nil by default. > That's for auto-revert-mode, which is enabled more often than its global > variant. Why would it be enabled more often? 'global-auto-revert-mode' is so easy to toggle (unlike setting up your own auto-revert-mode setup) and it corresponds to the feature of many contemporary code editors which is usually on by default.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 02:47:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 21:47:22 2022 Received: from localhost ([127.0.0.1]:38311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBSuY-0006rj-LC for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:47:22 -0500 Received: from sonic311-25.consmr.mail.ne1.yahoo.com ([66.163.188.206]:33930) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nBSuW-0006rU-NK for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:47:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642906035; bh=NKqU94ub+tZULqCw6R1oR+fh29H9gB8pTb0/GL+uM6Y=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=NuMufoRYbmAKgrkpgxv5V/MqzA5meJ64sjjnUAaS9C5v8DfWvGLsjj9hmUUhyxcht1iAxETYsXTYSmRaLX8LELatQKxdzLHM3eXE2KhUgtCoDkizOxMAwx9Q5vPTzsMxhiQPMHSkg4Z+eMYO6DIUCJi5Lg9GJFNsrUIUS+OJ3Qu10Dv9mkWlhQOySck8gyhQ72gXjmysNLjrfWK9skZHas1owOKFffulrKAgpHDjDLxAgm1tW8rQnYnNEauOnru8Gd0b+Op/jdqsv7zKDKCCNF7JA3RKzCW0NkaiSMmp4DdISxue/kt91ysl9E5KxnWqLjYxhTEA4HcfoLkpQzNRUQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642906035; bh=k+kNVXZ1e/19TaOugCZ7hZxIi+cExKrUWbS536Y2Iez=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=iGnQ18ZG3RkXzShC29B2wVnYFVb3ysGT6jzWu2EZikUnqUmX5eODJMaxOvWRzhIyj0CMYKwMLOs9zwJOnS4/YNAyklbOjEst8y0/R8c9XdfhLhXzpFpSB4fZ2Kmr4F4mpxJ58RZN8Xdr98pifqkLU2uFFSD31fUBVLcF+1lib06qJM4M0mEBECAEb4aeyuvb2UkPPpWmYhz8L6SGfMVdBvBoTzTkSYUMKo0UkIhw9WdA3erA7EAsax+xVg1+g5mF5/r2GGemBEeeggedgdRa2+1GGfvzBcvB7oR9VRz3zQqfXHqVIFLR4BsI+HgdD5eaq9u1jCcKAvGgxu74YbbmHg== X-YMail-OSG: G8lN5twVM1nEd1nrrRqZ_uIt9j.YYTGTv0Lf7FbgIU0nbVR6AWLu1pXsP_NbZXg bMMucaw5Acb0_TAkuVL0xo3r6By1glccWXCeVj7QohBWHO8z8Z10XxPVXq4eG4571p3cEmYw9flk WaBvaemvrKu2h7gSopOJrPHEx8Pq_pxy7b2NGHozTQaVBUr4tyln2X2AuajFYL1AoG2TAUgO78eP Iuy492kjhmXRBO455BvemmhqlQgJ48XeltrsyvYeO8YA7SFyZHM40g0GyI7fKFXZKXJvxOUj13yT o4NMyVH._uMYygflgowtOWGyFsi_tQeFNgrXeFKmzgLZz9HBdXl4hel2Bfmu1QZw.ZzjXBexHLBA Zrnz.LILkZ1_3gQ_5GKtZlnM9E1XfGFnayUj8vIthOHlyOhj6ld5K3Wf1JURjXtdOyOT6vUQLL5M sY_7bWjIbUHgWngaPJvRH26fcqQdsqw7KlQjw65RTCbMCZytupfTaTow1huNZPYv7Iyv8yiH28pi XezeWk4yUWpN2VNMQsIVSXYJYnpgkMBM5wDsIFdPOb.Ilz03onUDykYQmJuN50PjF4ulgayqfnQ3 nSvP.l__mHvdL170rnkMQHUwJvt1.k071cJ4ag4NGSJIiB0GzzutafDKTBwuijSxkTzshPsHeOux AZ0O.5zEeSRd8tIs8bFJ4qgLoYZc2a7IH9u5piIpVRWXQ_iCeMBM.EWbRnlHD3RQ39Ly.K.W4UY. TjtMX4MMidjPmu8K2zM6ZaQxrUym3bHBbSDRzmnqZiJnKiXpy5wl7JzD.K432XVn6A9NjMeloOvw EbE3fHhW6RVUEUFVrOL_Ca3jJsA7dQBTgt.aT5hU_bDdXYy_17yRWxkBTjchvFSYYgM3_Bzl6mtl TYQPBxdwHPdKzYthtTQteIbqTa_ApIrnO6m__U4gmQOQeBDA9L0tJqgcVE5ZZUY7tvd7OvW7Mibk Kz4N808HCasU1grBmqvidfeywZuOGn3ZrT3xurTJHWvXrs2dgIXqX67Dv0GVJdJNeyUGTcqsFx2G vUop.Fd1nSpp_NyPJYukDct2v7Qjqd4BD0kumXk.PeL.koI3OQVF0PhVigUO6WfTkzqUyOhke01T DP4rrVIYPN2Pw1MoNpcYOAMwhQ01vHJTU7i3DWIDuycmc1vufvm0Ck.C3IO7uAuPgLEaQ4bw6RfF J2MTtLt2xeZcU3VUaVQqWMeXIa55l8pjC0l1nYmjFfloWic0iiyntJdGm.jaVqjpCWuWxBp5fGhi YlK_q8T8BXw9VgtviXyfmHzU0Bn0jgtznlj2FsosYE4yH.syJHqaLFh8tX8mr0xnqq4akHKQAfq8 qtxFwX87ZA1V34gvu9cDlt3W5Ha2NUgIV69iL4kaZnj0yPuU8GaEP1BIIwu_DarNHcPf8YUZ61e0 oQmZ_xOlogIzoPopG3sz8SHLzTKqXeeR6YQ2T8dixOdWfsVyQV4QI49NJKCFzOK6.BzFGpotx46K aRCvHzAkzAn4QlaR0YenUtFBrJGbyOPinYfHoAXo1lMv_A2FaBdz97VHqqBM6XwMj88jUCs6D9u. 6nR_vHnhKQlwa4HO16Q9zaUzBfpD2rZm_t3IeoSGwoljhMSrqHr8fOxOxy3.5.maLXupXfX.fZO. blgIu2Wp4.A2iBU9PfNDtk.A._SgjcwXaTgH5Akl4GYspqV_29SSdw1D_PxNCHsNTmxFTyyfqnWJ SiwvQVPrphaHQqL6MY26fJyU.PXinskMK0t0J4xqAPB6GFRDAasx_kEHMJImvy6t7lGlueWIso0E 3.NQvzyU2myeJthmLJ_Ey5YqekwWbPMrsvpZ0YVGMaYKd7WDlAh_QdSiB_ENW64MyUfvmpWsu9tW FLap3YkIr.0hKiqSrhRAKBWhFxKgWbaeHgCbqgHp7UmwGG4_ZkWprypNryDJ2JjJQu.6jA60G44u JkQGZn3mRs8RWwItFcAoeGgG7GSpaL1G3_JPVKEKN3ufY5_ec3zie89akIlyywd6kMctkdHGZAi7 Y11e.j1mR_C9ioGz31Duya87abioczsL7EOKKHt2OdcrZyKnqf22VXCJt7NfUtuXQUchrOhmyeyh JxbWiik3SYNS9Pxn2c0.FV_9gTQB56xrIbiRRI..Gr4JV4Sqyn8u.Y7WvHAM.3WqOirBL1INpfql NqeJXJhu3x65Fe0Zu2myFKqRaM7E_uWkK75l8j_NgRED5utDlZgsfeVw52XZHBURTsrPmcdY9AW9 8PYWCC.QcTlB7hS1OL7Xl2QR7gfW04WBduQSKKv9MYVWk6VVM_a5KH7TA X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Sun, 23 Jan 2022 02:47:15 +0000 Received: by kubenode501.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID ba9451e4a27ccd974462fced1cf1d6e0; Sun, 23 Jan 2022 02:47:12 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Dmitry Gutov <dgutov@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> Date: Sun, 23 Jan 2022 10:47:07 +0800 In-Reply-To: <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> (Dmitry Gutov's message of "Sun, 23 Jan 2022 04:37:10 +0200") Message-ID: <87o843rwwk.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 233 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org, Ian Jackson <ijackson@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Dmitry Gutov <dgutov@HIDDEN> writes: > If it was really our recommendation, I think we'd set > auto-revert-use-notify to nil by default. That's for auto-revert-mode, which is enabled more often than its global variant. Thanks.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 02:37:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 21:37:23 2022 Received: from localhost ([127.0.0.1]:38302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBSkt-0006c2-Og for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:37:23 -0500 Received: from mail-wr1-f46.google.com ([209.85.221.46]:37675) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <raaahh@HIDDEN>) id 1nBSko-0006bX-7W for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 21:37:18 -0500 Received: by mail-wr1-f46.google.com with SMTP id ba4so7066752wrb.4 for <53432 <at> debbugs.gnu.org>; Sat, 22 Jan 2022 18:37:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=s7e53ZlEBBbgilk58UWjaMnaiZRc4/1nHOaIqhogauo=; b=KhkOgRmQ7xjd2VyOPOtaJhhbD1CBLKKbxMRTU4khDkLj2pTNuKymamb/z04fLFTgVW KVT9LAv82i6t2NBBe1mF8i/xfh6OVChjXUnXRpDN0tDJ60JOKuviRCcthMVSHT1Tthe/ 5IoqHx+ML8j3Hdrd4zevaIxuV2gpWjSeMnYoAfUnOF8bRrYWfR1z9veCEUnrjlrEelIn vJ2gaXViEHGsokz1lOpXPJbUBbKhj+JqZNKUtPPs14BKXNAKoBXVMtHVUBVSrKG05ToX XR/k2PCjwRw/Rn86mkWpjMWvDMqUPssfq9fyHk6hG4zxgHwpQYzCMqdjvhSar3+DWj2s vDCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=s7e53ZlEBBbgilk58UWjaMnaiZRc4/1nHOaIqhogauo=; b=vs2MEJ/99hIYRaQO5LVw1lBJTTTyilMywAzhJDJuqetp/0uqKoL3JH/b5I/toYTD4C GVeqboZnPS5sn/7zlA5MfD0nzTX90AZfJKCrly1fuzXkQbGtxEvH5EjtUjEcrNaMN6te jOefSSIK1R+GH/wc+LzNkvQjfbm9nIEVRtLF4xXBFTqGGltJ1pKtM8ifrQb0AC5DxFX7 v76zSE1PT7V/Mlg8CwmPJ+HybTljWZ//lLFMpwY6ta5u6hAj1gE7XZZJxcxv4IiTpbkF 3S+QqJTyKNOxJtxo6NiFdMZMBd8DJvVGAtSHskL7EV/wNljJOg8LtTgWOEWuhIccG1qR 2Jqw== X-Gm-Message-State: AOAM533a6X8jB/SWiFDLuzlOkksVJe4hiLDLj3BMVpqxGcpeta47cgQq cujYtpjk4OeEBYEJZgarEtG50BHPQLc= X-Google-Smtp-Source: ABdhPJwjRjVb10ExfaV7rghzKuzYq1yrzF5ax63ecXEXAA7mYudKc+op4OzbV13uXVnsS+k5g4Im2Q== X-Received: by 2002:a05:6000:81:: with SMTP id m1mr4264251wrx.385.1642905432314; Sat, 22 Jan 2022 18:37:12 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k37sm16001007wms.0.2022.01.22.18.37.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 22 Jan 2022 18:37:11 -0800 (PST) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] To: Eli Zaretskii <eliz@HIDDEN>, Ian Jackson <ijackson@HIDDEN> References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> <8335lfmu0q.fsf@HIDDEN> From: Dmitry Gutov <dgutov@HIDDEN> Message-ID: <7c4167fc-6c60-5888-cd16-6c6bd4ad210d@HIDDEN> Date: Sun, 23 Jan 2022 04:37:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <8335lfmu0q.fsf@HIDDEN> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -0.6 (/) X-Debbugs-Envelope-To: 53432 Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.6 (-) On 22.01.2022 21:48, Eli Zaretskii wrote: > Which is why we recommend turning off file-notifications when you turn > on global-auto-revert-mode. If it was really our recommendation, I think we'd set auto-revert-use-notify to nil by default.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 23 Jan 2022 01:00:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 20:00:21 2022 Received: from localhost ([127.0.0.1]:38239 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBREz-0004Cd-JB for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 20:00:21 -0500 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 <luangruo@HIDDEN>) id 1nBREx-0004CP-Gs for 53432 <at> 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_cTUb4VDWuPGeWhoPH64npFk7gfCL1c6NOVfD2bqURQxu7pc 1k1ghjdVJJYSzitHoXiQBmyuWm7xPwzhfIkItIha_IFFbL_yXaF0OtXg9ft7FJ0Ro9c38DVDS0qb .3mvhKiKw_SUL63ZO3kschVqA66GaoZpjG_frCWjW7qlbonDEuz97aAatxmZHjJ5PyUlOwIy5ABX Li8xEJEAebz3_wuBa4Wwq1XneiRZ5_3nLIwQ3SL3JbF4gsztjcxQv09XBiFeVFWwzgw0WbwWmLj0 4EYn5CCJovtuXM3sXkKq2snRauJutIxhH6HkDCLCxxUe8vrdSjXvoEjvXD6Ipm19nDd7CWQlRFe6 JCrgIg4KHzTGQoTU8ws7F0vBCD40fYxZpx1nekiEWFfnrDvv7vaO7zS5OPGtKG6RnOMvrH5bIlTU is.I_CoKLZSEVdtoaUnmi8PKFpWzRQxQ9LIbGszqh0iyQ.1dCxNjx_NSl63_rdBqwz..Wttrx3gx kFuum7mrwwV7XKtnOeKCEW8OPdjg4kMhw4m6OKgBaPmgP1wWmIAhUM3YYoinimrr_2Tfq9TCqLa5 6ZjHJcg0vmBzBBW0vxNYCrNtkhWos1Xj5atL9TZ8kf.pHDHMh1kg8.AqTXKaLSnTXnGpMHl7iyz4 JP.ei18ZjTw2oEDWpCTy2vk9Nk6nFKoj5SQJ8kloyFAJ9Zaffy09lHTnLdKgUA4Iad7IBOCgbMLo qjkncnbwa.WCR9HMwFlIwBUpYx.ZuV4vEVR8fVeRSEUtSijcHORm4gUewai4cw7e4yO.Vp_DIa6N IaTslRvZJVbMH2_y59e2rVCiYGGgHe_c8XHUmT6.xbGZttoQ95ktJHEis1cW._giuDBZlQnnG9f8 bPEDjVyRMAXlg2TK8_b7Yly8GxT9uBGYIVUKUg0Xna61sd6W32m7GvFsiRxNTia8Zm6Fq5YnRbt5 _bJqh4Ich2S8FYTiZbZ1.CnQgEhp1ofwXW2waxZKd7SPI7xGogk.O6OTUdCXCQ0Pn_BRm5QMfEGb 4flqDU3eEpGNlTbRReBxOv2Z5BNcMuZ8WqIgpC3Ggy4Q4TL0.599QBT8wWEA0jUVJqdFQN.Ixldu vDcSFh81TGTSrjJeb9MtqHtd.7Sgxr4HoSC7ckFIyJ7YdsB2NGwcQwFqTY7oQg09C4dAEGJt4Jzu ivoUIKDR.NI2xjpka5EBYgTN5mWYrwykaB8AchqQCYQpfQ25MFHQzaIDtqEncJ_srXHaUO4KxR4w m5vQOqxxzAwuyqmaUfdZMC5JYG886oLdliEk9LN4Qer0oGiHudVEgccvGlbCmsYvEd2xGgb9n5kM xiVW8f1azxP9ZXUbCSr0SyYu4_N81mKVl1rRiX9NNZuloPvOv0CJNihSL9.jJShUZtWprWLojaue zgkbbebUBXYNW6uBzKC6QDWzZWxzDXoPf94x4TbF4UCuxeE_CEnHHs84- X-Sonic-MF: <luangruo@HIDDEN> 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 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) From: Po Lu <luangruo@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy [and 1 more messages] References: <25067.17249.604070.872185@HIDDEN> <838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN> Date: Sun, 23 Jan 2022 09:00:02 +0800 In-Reply-To: <25068.23625.512978.147194@HIDDEN> (Ian Jackson's message of "Sat, 22 Jan 2022 19:34:33 +0000") Message-ID: <87a6fntgfh.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 2864 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: Eli Zaretskii <eliz@HIDDEN>, 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Ian Jackson <ijackson@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 22 Jan 2022 19:49:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 14:49:06 2022
Received: from localhost ([127.0.0.1]:37984 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nBMNm-0004qQ-1j
for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 14:49:06 -0500
Received: from eggs.gnu.org ([209.51.188.92]:47670)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1nBMNl-0004pw-1A
for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 14:49:05 -0500
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 <eliz@HIDDEN>)
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==;
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 <eliz@HIDDEN>)
id 1nBMNL-0008N9-Q3; Sat, 22 Jan 2022 14:48:44 -0500
Date: Sat, 22 Jan 2022 21:48:21 +0200
Message-Id: <8335lfmu0q.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Ian Jackson <ijackson@HIDDEN>
In-Reply-To: <25068.23625.512978.147194@HIDDEN> (message from
Ian Jackson on Sat, 22 Jan 2022 19:34:33 +0000)
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN>
<87r190wqo1.fsf@HIDDEN> <25068.23625.512978.147194@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 53432
Cc: luangruo@HIDDEN, 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Ian Jackson <ijackson@HIDDEN>
> Date: Sat, 22 Jan 2022 19:34:33 +0000
> Cc: 53432 <at> 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.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
Received: (at 53432) by debbugs.gnu.org; 22 Jan 2022 19:34:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 14:34:39 2022
Received: from localhost ([127.0.0.1]:37963 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1nBM9n-0004SD-D7
for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 14:34:39 -0500
Received: from permutation-city.chiark.greenend.org.uk
([212.13.197.230]:53966 helo=chiark.greenend.org.uk ident=Debian-exim)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <ijackson@HIDDEN>) id 1nBM9l-0004S2-Eg
for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 14:34:38 -0500
Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local
(return-path ijackson@HIDDEN)
id 1nBM9h-0006Tf-Ls; Sat, 22 Jan 2022 19:34:33 +0000
From: Ian Jackson <ijackson@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <25068.23625.512978.147194@HIDDEN>
Date: Sat, 22 Jan 2022 19:34:33 +0000
To: Eli Zaretskii <eliz@HIDDEN>,
Po Lu <luangruo@HIDDEN>
Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is
too busy [and 1 more messages]
In-Reply-To: <87r190wqo1.fsf@HIDDEN>,
<838rv8nua8.fsf@HIDDEN>
References: <25067.17249.604070.872185@HIDDEN>
<838rv8nua8.fsf@HIDDEN> <87r190wqo1.fsf@HIDDEN>
X-Mailer: VM 8.2.0b under 24.4.1 (i586-pc-linux-gnu)
X-Spam-Score: -0.6 (/)
X-Debbugs-Envelope-To: 53432
Cc: 53432 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)
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.
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.
It's probably happening to the occasional user right now, albeit very
rarely, and they probably think they just didn't hit the key properly
or something. I really dislike the idea that emacs is making our
users doubt themselves, by pretending the user didn't hit a key. I
don't think it's good enough for this to be "rare" or "only in unusual
situations" or "only when the computer is overloaded". We expect
emacs to be reliable and we need to make it so.
I'm obviously open to other suggestions for how to deal with this to
make sure that both keystrokes and file updates are not *lost*, only
possibly *delayed*. I don't really know the code so it is entirely
plausible that my approach is wrong.
Po Lu writes ("Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy"):
> I would rather not allocate anything on the heap to hold inotify events.
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.
Of course the unbounded memory consumption is a problem, as I write in
my FIXME. Allocating an undounded amount of memory on the stack each
time, as the current code does, is really very brave and seems to me
clearly worse than doing it amortised-approximately-once on the heap.
(But maybe SAFE_ALLOCA falls back to malloc for big requests anyway.)
> 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 ? 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.
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).
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.
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. But
maybe it would e OK if it is almost always used only with expert
reivew (eg, by code in other parts of emacs).
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;
Anyway my current patches rebase cleanly from 27 all the way to
master. It seems very likely that'll be true for whatever fix we come
up with. So the fix can be forward- or back-ported as people like.
> [Ian:]
> > 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.
Ian.
--
Ian Jackson <ijackson@HIDDEN> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 22 Jan 2022 06:45:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 22 01:45:37 2022 Received: from localhost ([127.0.0.1]:35635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nBA9Z-0007wj-4F for submit <at> debbugs.gnu.org; Sat, 22 Jan 2022 01:45:37 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1nBA9X-0007wW-BX for 53432 <at> debbugs.gnu.org; Sat, 22 Jan 2022 01:45:35 -0500 Received: from [2001:470:142:3::e] (port=46450 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 <eliz@HIDDEN>) id 1nBA9Q-0002Rf-IU; Sat, 22 Jan 2022 01:45:29 -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=5mH4fNwYWJe04VepCrIYTRIjGqScqMNUFVWS/GqzKGs=; b=QhX0IcFm6nCB SzkhCQZTeI3CirFUqmHCAarETozTt3+pxwLuUHyG6ez0mmZSoM81f9nTi53Nv0J6plvGPGrMo9H82 toBeHQg8Q6uZ+cDeC8idD5F4LvZQArTHroauX4AUpqlAm5wr7eQZ3tSVerq/Pl2QOc7oZBkDHXegw Pxx7AzvBIXRPgREYXceLeB5TOcbV+wQBU+pOfLmRr0MB4gU0EmquXm+6gqPDGkMWNJ6+nljPcSsN0 09oEMepQq3hLWyFhZxEKjaUr7cmdEhiyTci5akvM61YCXRyp8g4isvLAHwhsKQug12Ob2yWewl0IE MOfADbmP77tig/8AV5IS9A==; Received: from [87.69.77.57] (port=1417 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1nBA9L-0000tZ-HC; Sat, 22 Jan 2022 01:45:25 -0500 Date: Sat, 22 Jan 2022 08:45:03 +0200 Message-Id: <838rv8nua8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> In-Reply-To: <25067.17249.604070.872185@HIDDEN> (message from Ian Jackson on Fri, 21 Jan 2022 23:36:01 +0000) Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy References: <25067.17249.604070.872185@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 53432 Cc: 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Ian Jackson <ijackson@HIDDEN> > Date: Fri, 21 Jan 2022 23:36:01 +0000 > > I experienced a bug where my Emacs (Debian's emacs-lucid) would lose > keystrokes under pathological conditions. I tracked this down to the > keyboard input buffer filling up with inotify events. > > The attached patches have been rebased onto emacs-28 (fbc9b121e062) > and I have tested before-and-after versions in parallel to verify that > the bug appears in the upstream branch and has been fixed with my > patches. > > The bug was really quite severe in my (rather abusive) situation, with > Debian's emacs-lucid 26.1. With the upstream emacs-28 branch it > requires more effort, and loses fewer keys. I suspect that some more > sophisticated approach to inotify requests means it's harder to get > the buffer to fill up with the newer version. Unfortunately I am not > able to share my whole repro, but a key part is to visit the output > file from this > while yes | dd of=t bs=1 count=1000000; do : ; > with global-auto-revert-mode enabled. > > With my patches it is still possible to get emacs to perform very > poorly by abusing it this way, but at least all the keys arrive > eventually. I added some FIXMEs for further work that would be good, > but is not critical to fixing the bug. 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. 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 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?
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at 53432) by debbugs.gnu.org; 22 Jan 2022 00:38:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 21 19:38:42 2022 Received: from localhost ([127.0.0.1]:35369 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nB4QU-00041q-7G for submit <at> debbugs.gnu.org; Fri, 21 Jan 2022 19:38:42 -0500 Received: from sonic311-25.consmr.mail.ne1.yahoo.com ([66.163.188.206]:37748) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <luangruo@HIDDEN>) id 1nB4QS-00041Z-2G for 53432 <at> debbugs.gnu.org; Fri, 21 Jan 2022 19:38:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642811913; bh=rAQDU3l8Mu+O+TUUR2T8eXydRuGkg6zLILPDLyTOfl0=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=Ay0UzXAI4xs5/tCeHaNMemX/f3WJgfxpc1ncw8lY3PQ0tMgpnj1NtGcVPgSgyhQ3XGpI+ueXidy6bVQzXc6Hz/L4mOJj1K1dTEjKrIE7oMdHj05Jqho9QzLsl+waqyhJfSaEpg7MVYiX6RVH8oCsYJMx37nqqeDaKLHusnZC0b7Tmj5wvUf9VcPgeed7YT6M8EW3xcgqEpCakqp7h1Qqjbf79V4MqCWWRZ2yzfKfyrT720XtbwYk5uNQhnyTEZUVAQv3d9BlDfgtG1Jroz7J25rguLXN0EncsbMKxUKNUstlGi3ByaQ8rgZLH3JueEHR9omgECRoUtSisxkjPTqk5Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1642811913; bh=1P5KzYafp/06k6mmzZh7i1P9/oiKBtYDb0lcgVlU599=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=C4RCyY6bJWuS5ALIBfqnl0tFLR1Bo0hkHiz69qOflXMmI0WqelPR9SojQaByjBqcdmnofJkQcQN69HWnkEv/WhfnYCL6U3CSiYP9TF58bWoP+ezzm/qyhjlakk0GjR16JdsrZvpjW7IVnC72ChyslKH4wk1MddMwvd0qDd+vEtoNCbuvrdeXe1uvRdrgoyHbGAjMiOEkpI8u6XaPLLweIvZfdQRcHBR/PuRro/jGwvGZSKldw1XLgELoLAhXoeDdRaNvi8zkjrsdYvrekg8vEzGcP4LRzecnIhj+Y8kzFoTgZ0vCbi4+MpsqlOz0RhmF8X3TS8So6DxZcg5+1r30mA== X-YMail-OSG: flczw9AVM1kxpN7ew1_ftDc5eziseGvKi9Gx.U9gy4QFmtRzegveOGgsscZkCWP 2H0LrJuU4yCcvUVTZ5KTybrAVDAijh1xE6bU8K.cg9ypRIP3wFyU.X1cZC93ad0gGs302Z5eEHQk sw3l6Dx0CUhW5ldf1poyYm_elhBJY17ynA5EgODbmTBgJYuFz6_8jbD5NT2yCgv8LgzJoCCkEWnm iD6eMChsMvGFa7dD99JHZqHK3shanaCxRR6EpG5Zm24d2OWldXER4fqm9yUpsMPIPSMvH4eZbpvP Iqh0QT1xR9lWOrEhduZ9QEjAkk5xiliI3zVXo1DMZ..rf8A1MIdvRMdkjHscjyMxXWkB7u_xwRG2 hBOSXvkjTFE21WuaexSq5pra9jCPKuulfqL6zkc7oFUQFl0MOnkd3xfVSgD4JZgk52wOO34vN.nB f8XNYmROO8CqwCpvjjk0ypQtK.AO2piKM9cAgIxsY6ROWF1dBtv0x03jjEFGI1O.rD4FspiCwSqt cGkJObcZclokYvtzmw7u7n9jRbT3nxQYM6lZ2etGuXlxSC44imloFJsuY2CY5Oi_l48WOFA3JCWn vu78dtvhlcjOMLTk1MFOTYJ6VljZOwJoYqugZg8dpluhOLUeCn1XB7eBDjVa25Qon6bgJfsRUPw7 i9352Qb1UMPaeGMeAAT2FJRub9yPf3h_yl0M2UBDrpvY.BDBMyrUW1QvH3jOGPBvGbRNCXQrnZI7 lOQjN6Z1JbacV57SbTsxADfRLZ1bvgNbjEgNgC7uYootUXi.DV82QUWRG7Uwael_1udxC8HkTZKT hjQu1PGjPYxS9otJeYKfItkEUa4ujuKCUH6F6VEQqXJB7sxI_LinFOOgRKOSQVh16f6TqZ6AYaeF k70LHwGEWEmBvIMz2vmYCVfxKdFddj2_gAQHPhpIVTC_brD7e_dLG62MDSh84OlF2V84k0nnzm38 CeZdIx8pEvN_SFekFSeIlAoQ_RUasSo_cP6MyIC7yDB_CuD5umM7AZhCGbWPzGHnFY6mCzY7g1Ut YqWCA6gz.ms2dau.wCO5.NyuEUQTq4vdeeBPznuvu2NEE11SCFkZHfiy7bG_vxJh9csXIBpSN6SX Uj6_82armjiD4.tyDJRcpcfzmc2lxwWjDsjfoRvcmnTm8nhlHKAtguI4RUi5besbsx36oAdr9YUg q8bJ4yTmP1vdYrOTLMYa3GKwH85.Y8j6MBe58Cx2AG900K0Z1Z8gKmlZYf_k7OMcQP2tfIy9E8sw ShJzMIj4DvH4fhMMtgdqwVc4m20iAKOZr4FTQGRXQvC7P5z4dcsCdXCdqro6_dnxe4ih7g8WREoQ SZiiVXnQaZDvap6koL7weUVkpqqfNflzTWYZRMIs74vMLqN_ggxZVdeHXHQA4g5Kh0HGPe3L_b58 cPOPV7.q6L_W2p7YhYC5nqSc5kOrSYsAfHpUpn5m8ErB6cYzqZTls.Ca1PAnWseZduKSrCPGAmYJ p.OTCYAoTAqHXd8C0GNDqYDqzntt.KHb7hhdE02EdU7Ppbs5noGrR8.4oPuzagDai1LT1Crpiteb hvK8iKhEXwb6NC.3U2Zd9sELnGwMfFr6g90UG4i1toW8Tz3_kkCYjARCRCKiGxCp3BMbh0VxWByi jk70n0HgPqpwvKCMMTgooR8UCAYiPieMABm1ygLLyJAhBSCubKyWcscEzorgBAApPA5fsFHRiny5 vEdBA7KMI9G06JnXZnTl5GcAf8h..QhVgEOvfO1ht8L97yjoGT2WsgkHMvps8Ro4kYgDzUfw0YDN HrYRdxd7yaNozy_ApEU7b5aq5p5_92lTuaAcSe6ghIZFcW70gTUpGWiQ7.ivZJOxXoo3WvICHG9v 8Fe.EopfhU13mRX5YYQv97k9X0KsHfSjKsWyhl1orDqvsoRQHHVevTXKYOqoPuupeqX3S0bZEpDK 3D.vVAKNBohibWq2or5YzpRQSa.jLXT_OzkmuO.Y35tyEJsjm_u_GqcBvUrMZgBgku0u7kaA4vAp VutWtQhtfcfljPsRq3g985w33y_SN5CQO5pKR.eUJSDbo2Jh1xgpGV3aGh6PT25fLg_9_QsgE9t_ vMzTYqjTUUYS976AZ92lsy4r1NDnzDEGEzkEphWVdWap9YEZZ2VmSYYnpSlTEZhnzqjbAjOmAtq6 JpNmqJswL1K1iNsydDeC14tJ2MnbhQOMfJnb8yYw12Uo.KSRvkl3TOfOYasieJiUcWYUOv1yYyjT NDaCuM0VR20RO8kcK4SPh5TcdZHPZEFpKQnZwkz90lwxFTviYmzI- X-Sonic-MF: <luangruo@HIDDEN> Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Sat, 22 Jan 2022 00:38:33 +0000 Received: by kubenode504.mail-prod1.omega.sg3.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID c4405ec3a1e2c54e53b69b23d0b7e938; Sat, 22 Jan 2022 00:38:26 +0000 (UTC) From: Po Lu <luangruo@HIDDEN> To: Ian Jackson <ijackson@HIDDEN> Subject: Re: bug#53432: [PATCH] Avoid losing keyboard input when inotify is too busy References: <25067.17249.604070.872185@HIDDEN> Date: Sat, 22 Jan 2022 08:38:22 +0800 In-Reply-To: <25067.17249.604070.872185@HIDDEN> (Ian Jackson's message of "Fri, 21 Jan 2022 23:36:01 +0000") Message-ID: <87r190wqo1.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailer: WebService/1.1.19615 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Content-Length: 1567 X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 53432 Cc: 53432 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Ian Jackson <ijackson@HIDDEN> writes: > I experienced a bug where my Emacs (Debian's emacs-lucid) would lose > keystrokes under pathological conditions. I tracked this down to the > keyboard input buffer filling up with inotify events. > > The attached patches have been rebased onto emacs-28 (fbc9b121e062) > and I have tested before-and-after versions in parallel to verify that > the bug appears in the upstream branch and has been fixed with my > patches. > > The bug was really quite severe in my (rather abusive) situation, with > Debian's emacs-lucid 26.1. With the upstream emacs-28 branch it > requires more effort, and loses fewer keys. I suspect that some more > sophisticated approach to inotify requests means it's harder to get > the buffer to fill up with the newer version. Unfortunately I am not > able to share my whole repro, but a key part is to visit the output > file from this > while yes | dd of=t bs=1 count=1000000; do : ; > with global-auto-revert-mode enabled. > > With my patches it is still possible to get emacs to perform very > poorly by abusing it this way, but at least all the keys arrive > eventually. I added some FIXMEs for further work that would be good, > but is not critical to fixing the bug. I would rather not allocate anything on the heap to hold inotify events. 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. Thanks.
bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 21 Jan 2022 23:36:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 21 18:36:17 2022 Received: from localhost ([127.0.0.1]:35331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1nB3S5-0002NW-Gp for submit <at> debbugs.gnu.org; Fri, 21 Jan 2022 18:36:17 -0500 Received: from lists.gnu.org ([209.51.188.17]:45542) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <ijackson@HIDDEN>) id 1nB3S4-0002NP-EW for submit <at> debbugs.gnu.org; Fri, 21 Jan 2022 18:36:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34376) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <ijackson@HIDDEN>) id 1nB3S4-00080r-71 for bug-gnu-emacs@HIDDEN; Fri, 21 Jan 2022 18:36:16 -0500 Received: from permutation-city.chiark.greenend.org.uk ([212.13.197.230]:37436 helo=chiark.greenend.org.uk) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <ijackson@HIDDEN>) id 1nB3S2-0002SW-3Q for bug-gnu-emacs@HIDDEN; Fri, 21 Jan 2022 18:36:15 -0500 Received: by chiark.greenend.org.uk (Debian Exim 4.89 #1) with local (return-path ijackson@HIDDEN) id 1nB3Rp-0003yS-OQ for bug-gnu-emacs@HIDDEN; Fri, 21 Jan 2022 23:36:01 +0000 From: Ian Jackson <ijackson@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="DdFB866C/Z" Content-Transfer-Encoding: 7bit Message-ID: <25067.17249.604070.872185@HIDDEN> Date: Fri, 21 Jan 2022 23:36:01 +0000 To: bug-gnu-emacs@HIDDEN Subject: [PATCH] Avoid losing keyboard input when inotify is too busy Received-SPF: none client-ip=212.13.197.230; envelope-from=ijackson@HIDDEN; helo=chiark.greenend.org.uk X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.319, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) --DdFB866C/Z Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit I experienced a bug where my Emacs (Debian's emacs-lucid) would lose keystrokes under pathological conditions. I tracked this down to the keyboard input buffer filling up with inotify events. The attached patches have been rebased onto emacs-28 (fbc9b121e062) and I have tested before-and-after versions in parallel to verify that the bug appears in the upstream branch and has been fixed with my patches. The bug was really quite severe in my (rather abusive) situation, with Debian's emacs-lucid 26.1. With the upstream emacs-28 branch it requires more effort, and loses fewer keys. I suspect that some more sophisticated approach to inotify requests means it's harder to get the buffer to fill up with the newer version. Unfortunately I am not able to share my whole repro, but a key part is to visit the output file from this while yes | dd of=t bs=1 count=1000000; do : ; with global-auto-revert-mode enabled. With my patches it is still possible to get emacs to perform very poorly by abusing it this way, but at least all the keys arrive eventually. I added some FIXMEs for further work that would be good, but is not critical to fixing the bug. 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. Regards, Ian. --DdFB866C/Z Content-Type: application/octet-stream; name="0001-inotify.c-Document-hazard-of-unlimited-buffering.patch" Content-Disposition: attachment; filename="0001-inotify.c-Document-hazard-of-unlimited-buffering.patch" Content-Transfer-Encoding: base64 RnJvbSBhOTBiOWMzYzU0ZWFiZTRlOTQyOTkxMTQxN2E4ZjMxOTZiOTAzNmMyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8aWphY2tzb25AY2hpYXJrLmdyZWVuZW5k Lm9yZy51az4KRGF0ZTogRnJpLCAyMSBKYW4gMjAyMiAyMDoyODowNSArMDAwMApTdWJqZWN0OiBb UEFUQ0ggMS80XSAqIGlub3RpZnkuYzogRG9jdW1lbnQgaGF6YXJkIG9mIHVubGltaXRlZCBidWZm ZXJpbmcKCi0tLQogc3JjL2lub3RpZnkuYyB8IDMgKysrCiAxIGZpbGUgY2hhbmdlZCwgMyBpbnNl cnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvc3JjL2lub3RpZnkuYyBiL3NyYy9pbm90aWZ5LmMKaW5k ZXggZTkyYWQ0MGFiYy4uYjY3NmVhMjE2YSAxMDA2NDQKLS0tIGEvc3JjL2lub3RpZnkuYworKysg Yi9zcmMvaW5vdGlmeS5jCkBAIC0zMTYsNiArMzE2LDkgQEAgaW5vdGlmeV9jYWxsYmFjayAoaW50 IGZkLCB2b2lkICpfKQogICBpZiAoaW9jdGwgKGZkLCBGSU9OUkVBRCwgJnRvX3JlYWQpIDwgMCkK ICAgICByZXBvcnRfZmlsZV9ub3RpZnlfZXJyb3IgKCJFcnJvciB3aGlsZSByZXRyaWV2aW5nIGZp bGUgc3lzdGVtIGV2ZW50cyIsCiAJCQkgICAgICBRbmlsKTsKKyAgLy8gRklYTUU6IGZlZWRpbmcg dGhlIHZhbHVlIGZyb20gRklPTlJFQUQgdG8gYSBtZW1vcnkgYWxsb2NhdG9yIGlzIHVud2lzZQor ICAvLyBTYWRseSB0aGUgaW5vdGlmeSBldmVudCBidWZmZXIgcGFyc2luZyBhbGdvcml0aG0gaXMg bm90IGNhcGFibGUgb2YKKyAgLy8gaGFuZGxpbmcgdGhlIGNhc2Ugd2hlcmUgd2UgcmVhZCBvbmx5 IHBhcnQgb2YgYSBrZXJuZWwgZXZlbnQuCiAgIFVTRV9TQUZFX0FMTE9DQTsKICAgY2hhciAqYnVm ZmVyID0gU0FGRV9BTExPQ0EgKHRvX3JlYWQpOwogICBzc2l6ZV90IG4gPSByZWFkIChmZCwgYnVm ZmVyLCB0b19yZWFkKTsKLS0gCjIuMjAuMQoK --DdFB866C/Z Content-Type: application/octet-stream; name="0002-inotify.c-Use-a-buffer-from-the-heap.patch" Content-Disposition: attachment; filename="0002-inotify.c-Use-a-buffer-from-the-heap.patch" Content-Transfer-Encoding: base64 RnJvbSA2YTVkZDU3NjZhNTgwNjI1OGQ2NjVjYWIzNDNhMTAzYjU3MDViZjMyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8aWphY2tzb25AY2hpYXJrLmdyZWVuZW5k Lm9yZy51az4KRGF0ZTogRnJpLCAyMSBKYW4gMjAyMiAxOTo0Mjo0MyArMDAwMApTdWJqZWN0OiBb UEFUQ0ggMi80XSAqIGlub3RpZnkuYzogVXNlIGEgYnVmZmVyIGZyb20gdGhlIGhlYXAKCldlIGFy ZSBnb2luZyB0byBuZWVkIHRoaXMgYnVmZmVyIHRvIGJlIHBlcnNpc3RlbnQsIGJlY2F1c2Ugd2Ug bWF5IG5lZWQKdG8gc3RvcCBwcm9jZXNzaW5nIGl0IGhhbGZ3YXkgdGhyb3VnaCAoaWYgdGhlIG1h aW4gaW5wdXQgZXZlbnQgYnVmZmVyCmZpbGxzIHVwKS4KCkFsc28sIGdldHRpbmcgYSB2YWx1ZSBm cm9tIEZJT05SRUFEIGFuZCB0aGVuIGZlZWRpbmcgaXQgdG8gYWxsb2NhIGlzCmV2ZW4gbGVzcyB3 aXNlIHRoYW4gZmVlZGluZyBpdCB0byBtYWxsb2MuCi0tLQogc3JjL2lub3RpZnkuYyB8IDE3ICsr KysrKysrKysrLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTEgaW5zZXJ0aW9ucygrKSwgNiBkZWxl dGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zcmMvaW5vdGlmeS5jIGIvc3JjL2lub3RpZnkuYwppbmRl eCBiNjc2ZWEyMTZhLi5hZDAyMTY0YjM3IDEwMDY0NAotLS0gYS9zcmMvaW5vdGlmeS5jCisrKyBi L3NyYy9pbm90aWZ5LmMKQEAgLTQzLDYgKzQzLDkgQEAgQ29weXJpZ2h0IChDKSAyMDEyLTIwMjIg RnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCiAvKiBGaWxlIGhhbmRsZSBmb3IgaW5vdGlm eS4gICovCiBzdGF0aWMgaW50IGlub3RpZnlmZCA9IC0xOwogCitzdGF0aWMgc2l6ZV90IGlub3Rp ZnlfYnVmZmVyX2xlbiA9IDA7CitzdGF0aWMgY2hhciAqaW5vdGlmeV9idWZmZXIgPSBOVUxMOwor CiAvKiBBbGlzdCBvZiBmaWxlcyBiZWluZyB3YXRjaGVkLiAgV2Ugd2FudCB0aGUgcmV0dXJuZWQg ZGVzY3JpcHRvciB0bwogICAgYmUgdW5pcXVlIGZvciBldmVyeSB3YXRjaCwgYnV0IGlub3RpZnkg cmV0dXJucyB0aGUgc2FtZSBkZXNjcmlwdG9yCiAgICBXRCBmb3IgbXVsdGlwbGUgY2FsbHMgdG8g aW5vdGlmeV9hZGRfd2F0Y2ggd2l0aCB0aGUgc2FtZSBmaWxlLgpAQCAtMzE5LDkgKzMyMiwxMyBA QCBpbm90aWZ5X2NhbGxiYWNrIChpbnQgZmQsIHZvaWQgKl8pCiAgIC8vIEZJWE1FOiBmZWVkaW5n IHRoZSB2YWx1ZSBmcm9tIEZJT05SRUFEIHRvIGEgbWVtb3J5IGFsbG9jYXRvciBpcyB1bndpc2UK ICAgLy8gU2FkbHkgdGhlIGlub3RpZnkgZXZlbnQgYnVmZmVyIHBhcnNpbmcgYWxnb3JpdGhtIGlz IG5vdCBjYXBhYmxlIG9mCiAgIC8vIGhhbmRsaW5nIHRoZSBjYXNlIHdoZXJlIHdlIHJlYWQgb25s eSBwYXJ0IG9mIGEga2VybmVsIGV2ZW50LgotICBVU0VfU0FGRV9BTExPQ0E7Ci0gIGNoYXIgKmJ1 ZmZlciA9IFNBRkVfQUxMT0NBICh0b19yZWFkKTsKLSAgc3NpemVfdCBuID0gcmVhZCAoZmQsIGJ1 ZmZlciwgdG9fcmVhZCk7CisgIGlmICh0b19yZWFkID4gaW5vdGlmeV9idWZmZXJfbGVuKQorICAg IHsKKyAgICAgIGlub3RpZnlfYnVmZmVyID0geHJlYWxsb2MoaW5vdGlmeV9idWZmZXIsIHRvX3Jl YWQpOworICAgICAgaW5vdGlmeV9idWZmZXJfbGVuID0gdG9fcmVhZDsKKyAgICB9CisKKyAgc3Np emVfdCBuID0gcmVhZCAoZmQsIGlub3RpZnlfYnVmZmVyLCB0b19yZWFkKTsKICAgaWYgKG4gPCAw KQogICAgIHJlcG9ydF9maWxlX25vdGlmeV9lcnJvciAoIkVycm9yIHdoaWxlIHJlYWRpbmcgZmls ZSBzeXN0ZW0gZXZlbnRzIiwgUW5pbCk7CiAKQEAgLTMzMSw3ICszMzgsNyBAQCBpbm90aWZ5X2Nh bGxiYWNrIChpbnQgZmQsIHZvaWQgKl8pCiAKICAgZm9yIChzc2l6ZV90IGkgPSAwOyBpIDwgbjsg KQogICAgIHsKLSAgICAgIHN0cnVjdCBpbm90aWZ5X2V2ZW50ICpldiA9IChzdHJ1Y3QgaW5vdGlm eV9ldmVudCAqKSAmYnVmZmVyW2ldOworICAgICAgc3RydWN0IGlub3RpZnlfZXZlbnQgKmV2ID0g KHN0cnVjdCBpbm90aWZ5X2V2ZW50ICopICZpbm90aWZ5X2J1ZmZlcltpXTsKICAgICAgIExpc3Bf T2JqZWN0IGRlc2NyaXB0b3IgPSBJTlRfVE9fSU5URUdFUiAoZXYtPndkKTsKICAgICAgIExpc3Bf T2JqZWN0IHByZXZ0YWlsID0gZmluZF9kZXNjcmlwdG9yIChkZXNjcmlwdG9yKTsKIApAQCAtMzUx LDggKzM1OCw2IEBAIGlub3RpZnlfY2FsbGJhY2sgKGludCBmZCwgdm9pZCAqXykKICAgICAgICAg fQogICAgICAgaSArPSBzaXplb2YgKCpldikgKyBldi0+bGVuOwogICAgIH0KLQotICBTQUZFX0ZS RUUgKCk7CiB9CiAKIERFRlVOICgiaW5vdGlmeS1hZGQtd2F0Y2giLCBGaW5vdGlmeV9hZGRfd2F0 Y2gsIFNpbm90aWZ5X2FkZF93YXRjaCwgMywgMywgMCwKLS0gCjIuMjAuMQoK --DdFB866C/Z Content-Type: application/octet-stream; name="0003-inotify.c-Break-out-inotify_process_buffer.patch" Content-Disposition: attachment; filename="0003-inotify.c-Break-out-inotify_process_buffer.patch" Content-Transfer-Encoding: base64 RnJvbSBiYzQ2YWZiMzQ1MjRkOTdhMzU0YTYzNmM0NzY1NDRkYWVkZjU2MGNkIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8aWphY2tzb25AY2hpYXJrLmdyZWVuZW5k Lm9yZy51az4KRGF0ZTogRnJpLCAyMSBKYW4gMjAyMiAxOTo1MToyNSArMDAwMApTdWJqZWN0OiBb UEFUQ0ggMy80XSAqIGlub3RpZnkuYzogQnJlYWsgb3V0IGlub3RpZnlfcHJvY2Vzc19idWZmZXIK CldlIHBhc3MgdGhlIGJ1ZmZlciBmdWxsbmVzcyBpbiBhIGdsb2JhbCB2YXJpYWJsZS4gIFRoaXMg aXMgd2VpcmQgcmlnaHQKbm93LCBidXQgd2UgYXJlIGdvaW5nIHRvIHdhbnQgdGhpcyB0byBwZXJz aXN0IHNvIGl0IGlzIGNvbnZlbmllbnQgdG8KZG8gaXQgbm93LgotLS0KIHNyYy9pbm90aWZ5LmMg fCAxMyArKysrKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgMTIgaW5zZXJ0aW9ucygrKSwgMSBk ZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhL3NyYy9pbm90aWZ5LmMgYi9zcmMvaW5vdGlmeS5jCmlu ZGV4IGFkMDIxNjRiMzcuLjhhMzY4NWYyZjEgMTAwNjQ0Ci0tLSBhL3NyYy9pbm90aWZ5LmMKKysr IGIvc3JjL2lub3RpZnkuYwpAQCAtNDQsNiArNDQsNyBAQCBDb3B5cmlnaHQgKEMpIDIwMTItMjAy MiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KIHN0YXRpYyBpbnQgaW5vdGlmeWZkID0g LTE7CiAKIHN0YXRpYyBzaXplX3QgaW5vdGlmeV9idWZmZXJfbGVuID0gMDsKK3N0YXRpYyBzaXpl X3QgaW5vdGlmeV9idWZmZXJfZnVsbCA9IDA7CiBzdGF0aWMgY2hhciAqaW5vdGlmeV9idWZmZXIg PSBOVUxMOwogCiAvKiBBbGlzdCBvZiBmaWxlcyBiZWluZyB3YXRjaGVkLiAgV2Ugd2FudCB0aGUg cmV0dXJuZWQgZGVzY3JpcHRvciB0bwpAQCAtNzEsNiArNzIsOSBAQCBDb3B5cmlnaHQgKEMpIDIw MTItMjAyMiBGcmVlIFNvZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KIAogc3RhdGljIExpc3BfT2Jq ZWN0IHdhdGNoX2xpc3Q7CiAKK3N0YXRpYyB2b2lkCitpbm90aWZ5X3Byb2Nlc3NfYnVmZmVyICh2 b2lkKTsKKwogc3RhdGljIExpc3BfT2JqZWN0CiBtYXNrX3RvX2FzcGVjdHMgKHVpbnQzMl90IG1h c2spCiB7CkBAIC0zMzIsMTEgKzMzNiwxOCBAQCBpbm90aWZ5X2NhbGxiYWNrIChpbnQgZmQsIHZv aWQgKl8pCiAgIGlmIChuIDwgMCkKICAgICByZXBvcnRfZmlsZV9ub3RpZnlfZXJyb3IgKCJFcnJv ciB3aGlsZSByZWFkaW5nIGZpbGUgc3lzdGVtIGV2ZW50cyIsIFFuaWwpOwogCisgIGlub3RpZnlf YnVmZmVyX2Z1bGwgPSBuOworICBpbm90aWZ5X3Byb2Nlc3NfYnVmZmVyICgpOworfQorCitzdGF0 aWMgdm9pZAoraW5vdGlmeV9wcm9jZXNzX2J1ZmZlciAodm9pZCkKK3sKICAgc3RydWN0IGlucHV0 X2V2ZW50IGV2ZW50OwogICBFVkVOVF9JTklUIChldmVudCk7CiAgIGV2ZW50LmtpbmQgPSBGSUxF X05PVElGWV9FVkVOVDsKIAotICBmb3IgKHNzaXplX3QgaSA9IDA7IGkgPCBuOyApCisgIGZvciAo c3NpemVfdCBpID0gMDsgaSA8IGlub3RpZnlfYnVmZmVyX2Z1bGw7ICkKICAgICB7CiAgICAgICBz dHJ1Y3QgaW5vdGlmeV9ldmVudCAqZXYgPSAoc3RydWN0IGlub3RpZnlfZXZlbnQgKikgJmlub3Rp ZnlfYnVmZmVyW2ldOwogICAgICAgTGlzcF9PYmplY3QgZGVzY3JpcHRvciA9IElOVF9UT19JTlRF R0VSIChldi0+d2QpOwotLSAKMi4yMC4xCgo= --DdFB866C/Z Content-Type: application/octet-stream; name="0004-inotify-Pause-when-keyboard-input-is-suspended.patch" Content-Disposition: attachment; filename="0004-inotify-Pause-when-keyboard-input-is-suspended.patch" Content-Transfer-Encoding: base64 RnJvbSA3Yjk0ZjE4MjY4M2FlMTJlM2YzOWE4MmE5OTU3MjM5ZDliMzU4MzJlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBJYW4gSmFja3NvbiA8aWphY2tzb25AY2hpYXJrLmdyZWVuZW5k Lm9yZy51az4KRGF0ZTogRnJpLCAyMSBKYW4gMjAyMiAxOTo1NjoxMyArMDAwMApTdWJqZWN0OiBb UEFUQ0ggNC80XSBpbm90aWZ5OiBQYXVzZSB3aGVuIGtleWJvYXJkIGlucHV0IGlzIHN1c3BlbmRl ZAoKSWYgdGhlIGVtYWNzIG1haW4gdGhyZWFkIGNhbm5vdCBwcm9jZXNzIGV2ZW50cyBxdWlja2x5 IGVub3VnaCwgdGhlCmlucHV0IGJ1ZmZlciBjYW4gYmVjb21lIGZ1bGwuICBJZiB0aGF0IGhhcHBl bnMsIGV2ZW50cyBjYW4gZ2V0IGxvc3QuCgpUaGVyZSBpcyBhIG1lY2hhbmlzbSB0byBkZXRlY3Qg dGhpcyBpbiBrZXlib2FyZC5jLCBhbmQgcHJldmVudCBwZW9wbGUKZnJvbSBwdXR0aW5nIG1vcmUg c3R1ZmYgaW50byB0aGUgYnVmZmVyLCBidXQgaXQgd2FzIG5vdCB3aXJlZCB1cCB0bwp0aGUgaW5v dGlmeSBtYWNoaW5lcnkuICBTbyBoZWF2eSBpbm90aWZ5IGxvYWQgY2FuIGNhdXNlIGxvc3QKa2V5 c3Ryb2tlcyEKCkZpeCB0aGlzLgoKKiBpbm90aWZ5LmM6IEJlIGFibGUgdG8gcGF1c2UgYW5kIHJl c3VtZSB0aGUgcmVhZGluZywgcmV0YWluaW5nIHRoZQpidWZmZXJlZCBldmVudHMgYXMgbmVjZXNz YXJ5LgoqIGtleWJvYXJkLmM6IENhbGwgc3RvcF9pbm90aWZ5X2lucHV0IGFuZCByZXN1bWVfaW5v dGlmeV9pbnB1dC4KCkRldGFpbHMgb2YgdGhlIGFwcHJvYWNoIGFyZToKCiAtIFRoZSBgaWAgbG9v cCB2YXJpYWJsZSBpbiBgaW5vdGlmeV9wcm9jZXNzX2J1ZmZlcmAgYmVjb21lcyBhIGdsb2JhbAog ICB2YXJpYWJsZSwgc28gdGhhdCB3ZSBjYW4gcmV0YWluIG91ciBrbm93bGVkZ2Ugb2Ygd2hlcmUg d2Ugd2VyZS4KCiAtIEVuYWJsaW5nIG9yIGRpc2FibGluZyByZWFkaW5nIGZyb20gdGhlIGlub3Rp ZnkgZmQgaXMgbm93IGRvbmUgaW4gYQogICBzaW5nbGUgaWRlbXBvdGVudCBmdW5jdGlvbiB3aGlj aCBjaGVja3Mgd2hldGhlciAoaSkgaW5wdXQgaXMKICAgc3VzcGVuZGVkIChpaSkgdGhlIGJ1ZmZl ciBvZiB1bnByb2Nzc2VkIGlub3RpZnkgZXZlbnRzIGlzIGVtcHR5LgogICBIYXBwaWx5IGFkZF9y ZWFkX2ZkIGFuZCBkZWxldGVfcmVhZF9mZCBhcmUgaWRlbXBvdGVudC4KCiAtIE5ldyBob29rcyBh cmUgcHJvdmlkZWQgYnkgd2hpY2gga2V5Ym9hcmQuYyB0ZWxscyBpbm90aWZ5LmMgd2hlbgogICBp bnB1dCBpcyBiZWluZyBzdXNwZW5kZWQgYW5kIHVuc3VzcGVuZGVkLiAgU3VzcGVuZGluZyBpbnB1 dCBpcwogICBzdHJhaWdodGZvcndhcmQuICBVbnN1c3BlbmRpbmcgaXQgbWF5IGludm9sdmUgcHJv Y2Vzc2luZyBidWZmZXJlZAogICBldmVudHMgKGFuZCB0aGF0IG1pZ2h0IGNhdXNlIHRoZSBpbnB1 dCB0byBiZSBzdXNwZW5kZWQgYWdhaW4hKQoKSSBoYXZlIGNoZWNrZWQgdGhhdCB0aGlzIGZpeGVz IHRoZSBsb3N0IGlucHV0IGJ1Zywgd2hpY2ggSSBjYW4KcmVwcm9kdWNlIHdpdGggYSBjcmF6eSB0 ZXN0IHNldHVwLiAgV2l0aCBteSBwYXRjaCwgd2hlbiBlbWFjcyBpcwpwcm9jZXNzaW5nIHRvbyBt YW55IGlub3RpZnkgZXZlbnRzLCBpdCBjYW4gYmVjb21lIHJhdGhlciB1bnJlc3BvbnNpdmUKLSBi dXQgd2hlbiBpdCByZWNvdmVycywgYWxsIHRoZSBldmVudHMgYXJlIHRoZXJlLgoKVGVzdGVkLWJ5 OiBJYW4gSmFja3NvbiA8aWphY2tzb25AY2hpYXJrLmdyZWVuZW5kLm9yZy51az4KLS0tCiBzcmMv aW5vdGlmeS5jICB8IDU3ICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysrKystLS0tCiBzcmMva2V5Ym9hcmQuYyB8ICAyICsrCiBzcmMva2V5Ym9hcmQuaCB8ICA5ICsr KysrKysrCiAzIGZpbGVzIGNoYW5nZWQsIDY0IGluc2VydGlvbnMoKyksIDQgZGVsZXRpb25zKC0p CgpkaWZmIC0tZ2l0IGEvc3JjL2lub3RpZnkuYyBiL3NyYy9pbm90aWZ5LmMKaW5kZXggOGEzNjg1 ZjJmMS4uOTdjMGZkOWVmYSAxMDA2NDQKLS0tIGEvc3JjL2lub3RpZnkuYworKysgYi9zcmMvaW5v dGlmeS5jCkBAIC00Myw4ICs0MywxNSBAQCBDb3B5cmlnaHQgKEMpIDIwMTItMjAyMiBGcmVlIFNv ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KIC8qIEZpbGUgaGFuZGxlIGZvciBpbm90aWZ5LiAgKi8K IHN0YXRpYyBpbnQgaW5vdGlmeWZkID0gLTE7CiAKKy8qIEJ1ZmZlciBpcyBsaWtlIHRoaXM6Cisg KiAgIHxvb29vfD09PT09PT09PT09PT09PT09PT09PT18LS0tLS0tLS0tfAorICogICAwICAgIGRv bmUgICAgICAgICAgICAgICAgICAgZnVsbCAgICAgIGxlbgorICogIm9vb28iIGlzIGV2ZW50cyB3 ZSBoYXZlIHByb2Nlc3NlZCBpbnRvIHRoZSBrZXlib2FyZCBidWZmZXIuCisgKiAiPT09PSIgaXMg ZXZlbnRzIHdlIGhhdmUgcmVhZCBmcm9tIHRoZSBrZXJuZWwgYnV0IG5vdCBwcm9jZXNzZWQuCisg KiAiLS0tLSIgaXMgc3BhcmUgc3BhY2UgdGhhdCB3YXMgdXNlZCBvbiBhIHByZXZpb3VzIG9jY2Fz aW9uICAqLwogc3RhdGljIHNpemVfdCBpbm90aWZ5X2J1ZmZlcl9sZW4gPSAwOwogc3RhdGljIHNp emVfdCBpbm90aWZ5X2J1ZmZlcl9mdWxsID0gMDsKK3N0YXRpYyBzaXplX3QgaW5vdGlmeV9idWZm ZXJfZG9uZSA9IDA7CiBzdGF0aWMgY2hhciAqaW5vdGlmeV9idWZmZXIgPSBOVUxMOwogCiAvKiBB bGlzdCBvZiBmaWxlcyBiZWluZyB3YXRjaGVkLiAgV2Ugd2FudCB0aGUgcmV0dXJuZWQgZGVzY3Jp cHRvciB0bwpAQCAtNzQsNiArODEsOCBAQCBDb3B5cmlnaHQgKEMpIDIwMTItMjAyMiBGcmVlIFNv ZnR3YXJlIEZvdW5kYXRpb24sIEluYy4KIAogc3RhdGljIHZvaWQKIGlub3RpZnlfcHJvY2Vzc19i dWZmZXIgKHZvaWQpOworc3RhdGljIHZvaWQKK2lub3RpZnlfYWRkX29yX3JlbW92ZV9yZWFkaW5n X2ZkICh2b2lkKTsKIAogc3RhdGljIExpc3BfT2JqZWN0CiBtYXNrX3RvX2FzcGVjdHMgKHVpbnQz Ml90IG1hc2spCkBAIC0zMTksNiArMzI4LDE0IEBAIHJlbW92ZV93YXRjaCAoTGlzcF9PYmplY3Qg ZGVzY3JpcHRvciwgTGlzcF9PYmplY3QgaWQpCiBzdGF0aWMgdm9pZAogaW5vdGlmeV9jYWxsYmFj ayAoaW50IGZkLCB2b2lkICpfKQogeworICBpZiAoIGlub3RpZnlfYnVmZmVyX2RvbmUgIT0gaW5v dGlmeV9idWZmZXJfZnVsbCApCisgICAgeworICAgICAgaW5vdGlmeV9hZGRfb3JfcmVtb3ZlX3Jl YWRpbmdfZmQgKCk7CisgICAgICByZXR1cm47CisgICAgfQorCisgIC8vIEJ1ZmZlciBpcyBlbXB0 eS4gIFdlIHdpbGwgcmVzZXQgZG9uZSBhbmQgZnVsbCBhZnRlciByZWFkaW5nIGludG8gaXQuCisK ICAgaW50IHRvX3JlYWQ7CiAgIGlmIChpb2N0bCAoZmQsIEZJT05SRUFELCAmdG9fcmVhZCkgPCAw KQogICAgIHJlcG9ydF9maWxlX25vdGlmeV9lcnJvciAoIkVycm9yIHdoaWxlIHJldHJpZXZpbmcg ZmlsZSBzeXN0ZW0gZXZlbnRzIiwKQEAgLTMzNyw5ICszNTQsMTQgQEAgaW5vdGlmeV9jYWxsYmFj ayAoaW50IGZkLCB2b2lkICpfKQogICAgIHJlcG9ydF9maWxlX25vdGlmeV9lcnJvciAoIkVycm9y IHdoaWxlIHJlYWRpbmcgZmlsZSBzeXN0ZW0gZXZlbnRzIiwgUW5pbCk7CiAKICAgaW5vdGlmeV9i dWZmZXJfZnVsbCA9IG47CisgIGlub3RpZnlfYnVmZmVyX2RvbmUgPSAwOwogICBpbm90aWZ5X3By b2Nlc3NfYnVmZmVyICgpOworICBpbm90aWZ5X2FkZF9vcl9yZW1vdmVfcmVhZGluZ19mZCAoKTsK IH0KIAorLyogSWRlbXBvdGVudGx5IHByb2Nlc3MgZXZlbnRzIGZyb20gb3VyIGJ1ZmZlciBvZiB0 aGluZ3Mgd2UgaGF2ZSByZWFkCisgKiBmcm9tIHRoZSBrZXJuZWwsIGludG8gdGhlIGlucHV0IGV2 ZW50IGJ1ZmZlci4gIENhbGwgc2l0ZXMgc2hvdWxkCisgKiBjYWxsIGlub3RpZnlfYWRkX29yX3Jl bW92ZV9yZWFkaW5nX2ZkIGFmdGVyd2FyZHMuICAqLwogc3RhdGljIHZvaWQKIGlub3RpZnlfcHJv Y2Vzc19idWZmZXIgKHZvaWQpCiB7CkBAIC0zNDcsOSArMzY5LDE0IEBAIGlub3RpZnlfcHJvY2Vz c19idWZmZXIgKHZvaWQpCiAgIEVWRU5UX0lOSVQgKGV2ZW50KTsKICAgZXZlbnQua2luZCA9IEZJ TEVfTk9USUZZX0VWRU5UOwogCi0gIGZvciAoc3NpemVfdCBpID0gMDsgaSA8IGlub3RpZnlfYnVm ZmVyX2Z1bGw7ICkKKyAgLy8gRklYTUU6IElkZWFsbHkgaW4gdGhlIGZ1dHVyZSBzb21lIGFycmFu Z2VtZW50IHdvdWxkIGJlIG1hZGUgdG8KKyAgLy8gcHJpb3JpdGlzZSBrZXlib2FyZCBpbnB1dCBv dmVyIGlub3RpZnkgZXZlbnRzLCB3aGljaCB3b3VsZAorICAvLyBpbnZvbHZlIHVzaW5nIGEgdGln aHRlciBjb25kaXRpb24gdGhhbiBrYmRfb25faG9sZF9wLgorCisgIHdoaWxlKCBpbm90aWZ5X2J1 ZmZlcl9kb25lIDwgaW5vdGlmeV9idWZmZXJfZnVsbCAmJiAha2JkX29uX2hvbGRfcCAoKSApCiAg ICAgewotICAgICAgc3RydWN0IGlub3RpZnlfZXZlbnQgKmV2ID0gKHN0cnVjdCBpbm90aWZ5X2V2 ZW50ICopICZpbm90aWZ5X2J1ZmZlcltpXTsKKyAgICAgIHN0cnVjdCBpbm90aWZ5X2V2ZW50ICpl diA9CisJKHN0cnVjdCBpbm90aWZ5X2V2ZW50ICopICZpbm90aWZ5X2J1ZmZlcltpbm90aWZ5X2J1 ZmZlcl9kb25lXTsKICAgICAgIExpc3BfT2JqZWN0IGRlc2NyaXB0b3IgPSBJTlRfVE9fSU5URUdF UiAoZXYtPndkKTsKICAgICAgIExpc3BfT2JqZWN0IHByZXZ0YWlsID0gZmluZF9kZXNjcmlwdG9y IChkZXNjcmlwdG9yKTsKIApAQCAtMzY3LDEwICszOTQsMzIgQEAgaW5vdGlmeV9wcm9jZXNzX2J1 ZmZlciAodm9pZCkKICAgICAgICAgICBpZiAoZXYtPm1hc2sgJiBJTl9JR05PUkVEKQogCSAgICBy ZW1vdmVfZGVzY3JpcHRvciAocHJldnRhaWwsIHRydWUpOwogICAgICAgICB9Ci0gICAgICBpICs9 IHNpemVvZiAoKmV2KSArIGV2LT5sZW47CisgICAgICBpbm90aWZ5X2J1ZmZlcl9kb25lICs9IHNp emVvZiAoKmV2KSArIGV2LT5sZW47CiAgICAgfQogfQogCisvKiBJZGVtcG90ZW50bHkgc3RhcnQs IG9yIHN0b3AsIHJlYWRpbmcgZnJvbSB0aGUgaW5vdGlmeSBmZCwgYWNjb3JkaW5nCisgKiB0byB3 aGF0IGlzIHJlcXVpcmVkLiAgKi8KK3N0YXRpYyB2b2lkIGlub3RpZnlfYWRkX29yX3JlbW92ZV9y ZWFkaW5nX2ZkICh2b2lkKSB7CisgIGlmIChpbm90aWZ5ZmQgPj0gMCkgeworICAgIGlmICgga2Jk X29uX2hvbGRfcCAoKSB8fCBpbm90aWZ5X2J1ZmZlcl9kb25lICE9IGlub3RpZnlfYnVmZmVyX2Z1 bGwgKQorICAgICAgZGVsZXRlX3JlYWRfZmQgKGlub3RpZnlmZCk7CisgICAgZWxzZQorICAgICAg YWRkX3JlYWRfZmQgKGlub3RpZnlmZCwgJmlub3RpZnlfY2FsbGJhY2ssIE5VTEwpOworICB9Cit9 CisKKy8qIENhbGxlZCB3aGVuIGtleWJvYXJkIGJ1ZmZlciBpcyBnZXR0aW5nIGZ1bGwsIGtiZF9v bl9ob2xkX3AgYmVjb21lcyB0cnVlLiAqLwordm9pZCBzdG9wX2lub3RpZnlfaW5wdXQgKHZvaWQp IHsKKyAgaW5vdGlmeV9hZGRfb3JfcmVtb3ZlX3JlYWRpbmdfZmQgKCk7Cit9CisKKy8qIENhbGxl ZCB3aGVuIGJ1ZmZlciBjYW4gdGFrZSBtb3JlIGV2ZW50cywga2JkX29uX2hvbGRfcCBiZWNvbWVz IGZhbHNlICovCit2b2lkIHJlc3VtZV9pbm90aWZ5X2lucHV0ICh2b2lkKSB7CisgIGlub3RpZnlf cHJvY2Vzc19idWZmZXIoKTsKKyAgaW5vdGlmeV9hZGRfb3JfcmVtb3ZlX3JlYWRpbmdfZmQgKCk7 Cit9CisKIERFRlVOICgiaW5vdGlmeS1hZGQtd2F0Y2giLCBGaW5vdGlmeV9hZGRfd2F0Y2gsIFNp bm90aWZ5X2FkZF93YXRjaCwgMywgMywgMCwKICAgICAgICBkb2M6IC8qIEFkZCBhIHdhdGNoIGZv ciBGSUxFLU5BTUUgdG8gaW5vdGlmeS4KIApAQCAtNDQ3LDcgKzQ5Niw3IEBAIHJlbmFtZXMgKG1v dmVkLWZyb20gYW5kIG1vdmVkLXRvKS4KICAgICAgIGlmIChpbm90aWZ5ZmQgPCAwKQogCXJlcG9y dF9maWxlX25vdGlmeV9lcnJvciAoIkZpbGUgd2F0Y2hpbmcgaXMgbm90IGF2YWlsYWJsZSIsIFFu aWwpOwogICAgICAgd2F0Y2hfbGlzdCA9IFFuaWw7Ci0gICAgICBhZGRfcmVhZF9mZCAoaW5vdGlm eWZkLCAmaW5vdGlmeV9jYWxsYmFjaywgTlVMTCk7CisgICAgICBpbm90aWZ5X2FkZF9vcl9yZW1v dmVfcmVhZGluZ19mZCAoKTsKICAgICB9CiAKICAgZW5jb2RlZF9maWxlX25hbWUgPSBFTkNPREVf RklMRSAoZmlsZW5hbWUpOwpkaWZmIC0tZ2l0IGEvc3JjL2tleWJvYXJkLmMgYi9zcmMva2V5Ym9h cmQuYwppbmRleCA5ODY1YmM5YWRkLi4xNzFiZGNmMWQ1IDEwMDY0NAotLS0gYS9zcmMva2V5Ym9h cmQuYworKysgYi9zcmMva2V5Ym9hcmQuYwpAQCAtMzY1Nyw2ICszNjU3LDcgQEAga2JkX2J1ZmZl cl9zdG9yZV9idWZmZXJlZF9ldmVudCAodW5pb24gYnVmZmVyZWRfaW5wdXRfZXZlbnQgKmV2ZW50 LAogICAgICAgICAgIGhvbGRfa2V5Ym9hcmRfaW5wdXQgKCk7CiAgICAgICAgICAgdW5yZXF1ZXN0 X3NpZ2lvICgpOwogICAgICAgICAgIHN0b3BfcG9sbGluZyAoKTsKKwkgIHN0b3BfaW5vdGlmeV9p bnB1dCAoKTsKICAgICAgICAgfQogI2VuZGlmCS8qIHN1YnByb2Nlc3NlcyAqLwogICAgIH0KQEAg LTM4NDksNiArMzg1MCw3IEBAIGtiZF9idWZmZXJfZ2V0X2V2ZW50IChLQk9BUkQgKiprYnAsCiAg ICAgICB1bmhvbGRfa2V5Ym9hcmRfaW5wdXQgKCk7CiAgICAgICByZXF1ZXN0X3NpZ2lvICgpOwog ICAgICAgc3RhcnRfcG9sbGluZyAoKTsKKyAgICAgIHJlc3VtZV9pbm90aWZ5X2lucHV0ICgpOwog ICAgIH0KICNlbmRpZgkvKiBzdWJwcm9jZXNzZXMgKi8KIApkaWZmIC0tZ2l0IGEvc3JjL2tleWJv YXJkLmggYi9zcmMva2V5Ym9hcmQuaAppbmRleCAwM2FhOTZhZDRiLi5hODMyZDA4YzJiIDEwMDY0 NAotLS0gYS9zcmMva2V5Ym9hcmQuaAorKysgYi9zcmMva2V5Ym9hcmQuaApAQCAtNDk5LDQgKzQ5 OSwxMyBAQCBrYmRfYnVmZmVyX3N0b3JlX2V2ZW50X2hvbGQgKHN0cnVjdCBpbnB1dF9ldmVudCAq ZXZlbnQsCiAKIElOTElORV9IRUFERVJfRU5ECiAKKy8qIERlZmluZWQgaW4gaW5vdGlmeS5jICov CisjaWZkZWYgSEFWRV9JTk9USUZZCitleHRlcm4gdm9pZCBzdG9wX2lub3RpZnlfaW5wdXQgKHZv aWQpOworZXh0ZXJuIHZvaWQgcmVzdW1lX2lub3RpZnlfaW5wdXQgKHZvaWQpOworI2Vsc2UKK0lO TElORSB2b2lkIHN0b3BfaW5vdGlmeV9pbnB1dCAodm9pZCkgeyB9CitJTkxJTkUgdm9pZCByZXN1 bWVfaW5vdGlmeV9pbnB1dCAodm9pZCkgeyB9CisjZW5kaWYKKwogI2VuZGlmIC8qIEVNQUNTX0tF WUJPQVJEX0ggKi8KLS0gCjIuMjAuMQoK --DdFB866C/Z Content-Type: text/plain; charset=us-ascii Content-Description: .signature Content-Transfer-Encoding: 7bit -- Ian Jackson <ijackson@HIDDEN> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter. --DdFB866C/Z--
Ian Jackson <ijackson@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#53432; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.