Received: (at 79777) by debbugs.gnu.org; 15 Nov 2025 17:29:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 15 12:29:41 2025
Received: from localhost ([127.0.0.1]:36186 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vKK5l-0004Nl-DZ
for submit <at> debbugs.gnu.org; Sat, 15 Nov 2025 12:29:41 -0500
Received: from [109.224.244.116] (port=29731 helo=mail-244116.protonmail.ch)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vKK5i-0004NU-LG
for 79777 <at> debbugs.gnu.org; Sat, 15 Nov 2025 12:29:39 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1763227772; x=1763486972;
bh=naf8m15cPwPbS5KZcY5rlwvyCswlq9DUISZbZWEOltY=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=jDPXF+D29kdeCib9PudABdf31iDqdcIm9yXKyhIsj04M7JwABMB2tcOhqcgm8Gq6N
P6dmzH1/UWZs/aDr3kKHVbrDVVxPo04lI0KKQj7TbNBhs7P0Zpif3z14yeQ0Au8vud
vCBA7x7HM+mMUzXAp/BvI1uH/7VsHCIoiXiN8jfqRPyvbIpe0TGs0032r1EHcxnlBH
05ht8zF4G0CEArCcvsGF3EI1lxPHxelD5x0uWHwKftAdRJa7EO9JOp6uYw8FmrgmgI
sewARb67WqELMa/eYECT0MqeOg92KOXj1YF9sXC6l3w7VN1LQV/0WjX1FAHW5UyYQ4
h37zrMbM9KCTg==
Date: Sat, 15 Nov 2025 17:29:28 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87346fi4qz.fsf@HIDDEN>
In-Reply-To: <868qg7o76o.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN>
<86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN>
<86v7jk5xfy.fsf@HIDDEN> <86zf8nocyp.fsf@HIDDEN>
<878qg7txm2.fsf@HIDDEN> <868qg7o76o.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 74f653ecc51a81239ca384adf32fc77b9f8abcb9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 2.2 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: "Eli Zaretskii" writes: >> Date: Sat, 15 Nov 2025 10:10:36
+0000 >> From: Pip Cet >> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org,
eggert@HIDDEN, dmitry@HIDDEN >> >> "Eli Zaretskii" writes: >> >>
> Ping! Any [...]
Content analysis details: (2.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[109.224.244.116 listed in bl.score.senderscore.com]
0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[109.224.244.116 listed in wl.mailspike.net]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[109.224.244.116 listed in sa-trusted.bondedsender.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (pipcet[at]protonmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.9 SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record (softfail)
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: "Eli Zaretskii" writes: >> Date: Sat, 15 Nov 2025 10:10:36
+0000 >> From: Pip Cet >> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org,
eggert@HIDDEN, dmitry@HIDDEN >> >> "Eli Zaretskii" writes: >> >>
> Ping! Any [...]
Content analysis details: (1.2 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.0 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[109.224.244.116 listed in bl.score.senderscore.com]
0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
[109.224.244.116 listed in wl.mailspike.net]
0.0 RCVD_IN_VALIDITY_SAFE_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[109.224.244.116 listed in sa-trusted.bondedsender.org]
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (pipcet[at]protonmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.9 SPF_HELO_SOFTFAIL SPF: HELO does not match SPF record (softfail)
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
-1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list
manager
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Sat, 15 Nov 2025 10:10:36 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dm=
itry@HIDDEN
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> > Ping! Any objections to installing the patch I proposed (reproduced
>> > below for your convenience)? If there are no objections, I will post
>> > a more complete patch with the comment I promised, so we could discuss
>> > the comment, per Pip's request.
>>
>> No objections, and I think Spencer's suggestion to start a conditional
>> rewrite of this function would make the comment less relevant; if there
>> are no other objections, I'd suggest to install this with a comment that
>> makes sense to you.
>
> Does this mean you don't need to have a review of the comment before I
> install the change?
That's correct, yes.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 15 Nov 2025 11:40:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 15 06:40:28 2025 Received: from localhost ([127.0.0.1]:34151 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vKEdn-0002oQ-OA for submit <at> debbugs.gnu.org; Sat, 15 Nov 2025 06:40:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44202) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vKEdk-0002ns-Ns for 79777 <at> debbugs.gnu.org; Sat, 15 Nov 2025 06:40:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vKEdd-0002OO-Vd; Sat, 15 Nov 2025 06:40:17 -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=+g/DC/EPtK3sIHuUIWGFvU5dsiCfs/EeNjr6L7gjPrM=; b=XYTlYQNUJod5 tHueC/c8NEhp7Nhg61avQu3NpBtEA3KlmCXpgawye/8GNX7Q8DGRFZ1cehZnuMxU7BTcHKUnkV7Kx yygTbPt6fGny0Td2DlQViwr4pL+oNrsG+61Uy2v5+XcMgnbNGpiKnJp+VejZHIXiC2eT+yF3vJtYK 7zjMdoVNIeg08Tc7mW6Y7QOM6jxO+5RvXAl/po04cnCV6QfkpqAB7MYYGVhMyUy42vBKxUriktZlx Te+I+vnwdG+mzLrNvlrG4XqOCicqJr9hIgwQ2oMFHXBms7Wbxj7gzvKNhx96LbXllZfC1iqKAYMUx f2hGtp5N5veGezetwSHrRw==; Date: Sat, 15 Nov 2025 13:40:15 +0200 Message-Id: <868qg7o76o.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <878qg7txm2.fsf@HIDDEN> (message from Pip Cet on Sat, 15 Nov 2025 10:10:36 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> <86zf8nocyp.fsf@HIDDEN> <878qg7txm2.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (---) > Date: Sat, 15 Nov 2025 10:10:36 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > Ping! Any objections to installing the patch I proposed (reproduced > > below for your convenience)? If there are no objections, I will post > > a more complete patch with the comment I promised, so we could discuss > > the comment, per Pip's request. > > No objections, and I think Spencer's suggestion to start a conditional > rewrite of this function would make the comment less relevant; if there > are no other objections, I'd suggest to install this with a comment that > makes sense to you. Does this mean you don't need to have a review of the comment before I install the change?
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 15 Nov 2025 10:10:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 15 05:10:52 2025 Received: from localhost ([127.0.0.1]:33871 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vKDF5-0007Pv-Rf for submit <at> debbugs.gnu.org; Sat, 15 Nov 2025 05:10:52 -0500 Received: from mail-244124.protonmail.ch ([109.224.244.124]:47491) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vKDF3-0007Pf-0Z for 79777 <at> debbugs.gnu.org; Sat, 15 Nov 2025 05:10:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1763201442; x=1763460642; bh=//JeFcXBggsUYz+2M3zwWKiGLf3kQXTv0XVmKT1sQzo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=RWZ1hryUIYnMzDocOu9gBmj0pRNohtdQZvSV2p2TgcYIsdQb/0ANZayw7eyrg2tNk ai4RRlvWGHQXksJR+vRMw5HRw8CCt/EX00yA7oIg9vr2aoSCbs1Di9eIbL444g7LgM mdPyozmpjS0K+UDAPzVM0M0gosfwKF+rivkejxJOqWSBepwbqXlBNsVg4AL0oG/CSN JTzGnFer/QUWtpekQ/WgBEalOHmK9/7NFDYMj3/RMkKyN56NPdWzPiFvr24zdUKLig fokyn5swwTTb6xIkxo1yAIkzsHdsuznRP+0pFLfSs+k98CFHPjlwMnbjzsrHc5Wsle kcgwCXM/DNowA== Date: Sat, 15 Nov 2025 10:10:36 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <878qg7txm2.fsf@HIDDEN> In-Reply-To: <86zf8nocyp.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> <86zf8nocyp.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: cc28fcce5592b12d47e947dbbe709dcf75d3f0e8 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: > Ping! Any objections to installing the patch I proposed (reproduced > below for your convenience)? If there are no objections, I will post > a more complete patch with the comment I promised, so we could discuss > the comment, per Pip's request. No objections, and I think Spencer's suggestion to start a conditional rewrite of this function would make the comment less relevant; if there are no other objections, I'd suggest to install this with a comment that makes sense to you. Thanks! Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 15 Nov 2025 09:35:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 15 04:35:37 2025
Received: from localhost ([127.0.0.1]:33732 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vKCgz-0005xE-D6
for submit <at> debbugs.gnu.org; Sat, 15 Nov 2025 04:35:37 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:53228)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vKCgx-0005wp-Id
for 79777 <at> debbugs.gnu.org; Sat, 15 Nov 2025 04:35:35 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vKCgr-00030w-34; Sat, 15 Nov 2025 04:35: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=s3S+ptLmeRZRMPPyB20DE5mtNwC0K84fD49piudt6J4=; b=G7lh5B47tHqs
e5YsMEsvURiQKSpPqHhmisXQUJG20myaOu+JjAO6onvug/44IzAQMcsL5lNc1Rr4aUj86XXeaE0Hd
isOjLiC8wn1kYOoAVPZmNOst2XA+Fk9T6lr8nEMg+fgyJbolgXDz9VbEygWoCfVjp7UXkMP0KJzA0
uuZJjUfysYfYYjYrXhOsuTFHgvI+d/PWB/VJIE4ZUjG/MYMCEcLiNf/rKTcfQdq+71EUvArxBuKCy
QJ4JgqR2walAUddlYap7oJESXFHc+NUdGsJY8HKITXESNKrBKQRhl0/PnXnJtGVSajSbL2sauSo7o
GaNhgA4HDwSul7dNf2P+iw==;
Date: Sat, 15 Nov 2025 11:35:26 +0200
Message-Id: <86zf8nocyp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: pipcet@HIDDEN, sbaugh@HIDDEN
In-Reply-To: <86v7jk5xfy.fsf@HIDDEN> (message from Eli Zaretskii on Sat, 08
Nov 2025 17:57:37 +0200)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN>
<ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN>
<87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN>
<87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN>
<877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@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 (---)
Ping! Any objections to installing the patch I proposed (reproduced
below for your convenience)? If there are no objections, I will post
a more complete patch with the comment I promised, so we could discuss
the comment, per Pip's request.
Here's the proposed patch:
diff --git a/src/process.c b/src/process.c
index 86e83e5..8445246 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5844,6 +5844,11 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (nfds == 0)
{
+ if (!read_kbd && update_tick != process_tick)
+ {
+ got_some_output = status_notify (NULL, wait_proc);
+ if (do_display) redisplay_preserve_echo_area (113);
+ }
/* Exit the main loop if we've passed the requested timeout,
or have read some bytes from our wait_proc (either directly
in this call or indirectly through timers / process filters),
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 9 Nov 2025 17:45:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 09 12:45:27 2025 Received: from localhost ([127.0.0.1]:60066 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vI9Ti-0002eB-PH for submit <at> debbugs.gnu.org; Sun, 09 Nov 2025 12:45:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vI9Tf-0002dk-0p for 79777 <at> debbugs.gnu.org; Sun, 09 Nov 2025 12:45:25 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vI9TX-0001W8-RX; Sun, 09 Nov 2025 12:45:15 -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=NiithMzWcl4MofviYQUSGBw/wtKReiWetl5kYXivgfI=; b=puJLYNwFF1Xg RPdYmtXIpL3svORisLO8evz7Eemg6kHg6ZrArRJjUEKDCQ64T+hOnQsy2S/hBal04B296bFyPEGtY bl1lIInHHjcvgQ8Jt7A/DpcycsL5wm5sNZ1KtQaSrou06a+OlknMD3UlNLhFbVCJ23DlZdY7prH1H HaL0Fs/quOyxojnNFAGgA5EkJS08XR5ih/i9ONfqpC6rbo4wSWrMBHjOLg6MYFr7TpHHd2OXobl5A /IZrxGh8950gVVGSLjlTHsGed8oIsTK9yuKGiNuQJCQK5xjTnPjJcUuoW0ZkmrZBjXH/hs2BBrdB7 7ksiioHntWnyY9v+JxdKHw==; Date: Sun, 09 Nov 2025 19:45:12 +0200 Message-Id: <86ms4v3xsn.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <iero6pbktfg.fsf@HIDDEN> (message from Spencer Baugh on Sun, 09 Nov 2025 12:27:31 -0500) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> <87seeo5ez2.fsf@HIDDEN> <868qgf67ff.fsf@HIDDEN> <iero6pbktfg.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: pipcet@HIDDEN, 79777 <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: Spencer Baugh <sbaugh@HIDDEN> > Cc: Pip Cet <pipcet@HIDDEN>, 79777 <at> debbugs.gnu.org, > eggert@HIDDEN, dmitry@HIDDEN > Date: Sun, 09 Nov 2025 12:27:31 -0500 > > Eli Zaretskii <eliz@HIDDEN> writes: > > and a loop which calls sleep-for whose behavior for various kinds of > > input is not well documented (e.g., I could argue that it is valid for > > sleep-for to postpone everything in Emacs, and the only reason I won't > > do that is because the code clearly shows the original intent of > > reading output from subprocesses when read_kbd is zero). > > I want to address this before getting to other things. > > Eli, as I have said repeatedly now in this discussion, sleep-for is not > required to trigger this bug. If the (sleep-for 1) in my reproducer is > replaced with (accept-process-output nil 1), the bug still happens. > > The bug happens regardless of whatever the precise semantics of > sleep-for is or should be, because the bug happens without using > sleep-for at all. > > So whatever arguments you could or could not make about sleep-for, they > are irrelevant to this bug, and to fixing this bug. Please just stop > mentioning sleep-for entirely. Sorry, this is not useful. I wrote what I wrote because I meant it. If you want this discussion to be efficient and rational, just drop the attitude, and start taking my arguments and opinions seriously and at face value. (Yes, accept-process-output also calls wait_reading_process_output with read_kbd = 0, I know that. But that doesn't in any way invalidate what I wrote, if you want to listen.)
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 9 Nov 2025 17:27:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 09 12:27:41 2025 Received: from localhost ([127.0.0.1]:59974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vI9CW-0001iv-82 for submit <at> debbugs.gnu.org; Sun, 09 Nov 2025 12:27:41 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41295) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vI9CT-0001i7-8z for 79777 <at> debbugs.gnu.org; Sun, 09 Nov 2025 12:27:37 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever In-Reply-To: <868qgf67ff.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 09 Nov 2025 08:34:12 +0200") References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> <87seeo5ez2.fsf@HIDDEN> <868qgf67ff.fsf@HIDDEN> Date: Sun, 09 Nov 2025 12:27:31 -0500 Message-ID: <iero6pbktfg.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1762709251; bh=xp53GivMnRlK7efrJYblKDN1B3b0CJou4uO02lcxTdg=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=hK948mSwLkRLLOP0E7Ng3NQy6UjOYKi8PqN4ZZ8PN97rQQRyS8XCjZf5fX966M+DI q67Zdl1vnxebCBN8A3x+nDkTeScev/Jghvr2GCAF7Mye5MhgwDsNUJ2lX8dTF2VpnL n9GuegTjGBV8Xc7edS50zRYW7pyDgEd7uOW1eK11MxaYkU7F2HfHhsZ0FCSvw3ctEy 7Zgq3WTD3rpYAhtbjHWpjIANfbQWNORb3e39o/PnGRTpPu95aunVBiQCB1VTnu7GTM Gk0oYtHeHeGikV/NoegXJgKv4OYJdXiog7eCrFHFSGG+j9/HCqBH7nbQlEbiYlQiT+ KRNqcupDow25A== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, Pip Cet <pipcet@HIDDEN>, eggert@HIDDEN, 79777 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: > and a loop which calls sleep-for whose behavior for various kinds of > input is not well documented (e.g., I could argue that it is valid for > sleep-for to postpone everything in Emacs, and the only reason I won't > do that is because the code clearly shows the original intent of > reading output from subprocesses when read_kbd is zero). I want to address this before getting to other things. Eli, as I have said repeatedly now in this discussion, sleep-for is not required to trigger this bug. If the (sleep-for 1) in my reproducer is replaced with (accept-process-output nil 1), the bug still happens. The bug happens regardless of whatever the precise semantics of sleep-for is or should be, because the bug happens without using sleep-for at all. So whatever arguments you could or could not make about sleep-for, they are irrelevant to this bug, and to fixing this bug. Please just stop mentioning sleep-for entirely.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 9 Nov 2025 06:34:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Nov 09 01:34:25 2025 Received: from localhost ([127.0.0.1]:56796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHz0K-0001bF-Oq for submit <at> debbugs.gnu.org; Sun, 09 Nov 2025 01:34:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39918) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHz0I-0001b9-C7 for 79777 <at> debbugs.gnu.org; Sun, 09 Nov 2025 01:34:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHz0B-0007Er-B6; Sun, 09 Nov 2025 01:34:15 -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=6UrY+qtfK1WQdrzRpiNQQkOB+S/jIzoB/cAlH1BHCAY=; b=QftMLT9G0acs pALILLOLv110t/57YYkUzFYIlw1RRPss09VIEXcmIYffZkUaGAuy/cn7MaknBKqEG/SGfrXmBaftT P3FeEy56i+rD1Osod10oJZSPIN8d0SvdBzCtXtiQJkSTs28cw4bjsB2dLSEz8LnJLnqfxnf1C+UhU 9pjbFc6WcCSGDz0Q83zvvA0Hi1qesKMEPEVj9C4NOZm74Ex0OsyoBPPQbhlbsUwoFPL3RtAThhDQT MBJi4b81j4A1HF5CWYzuq7AFMqewxl1JyAh9VDQcleRr3Boi52otyRZzad4IzeoKTmS+2HbtFRfHr hkVxpJDjNd7kLmry7N2uHw==; Date: Sun, 09 Nov 2025 08:34:12 +0200 Message-Id: <868qgf67ff.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87seeo5ez2.fsf@HIDDEN> (message from Pip Cet on Sat, 08 Nov 2025 22:36:40 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> <87seeo5ez2.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (---) > Date: Sat, 08 Nov 2025 22:36:40 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > Another deviation from your patch is that I added read_kbd to the > > condition, so as not to affect callers that we haven't considered. > > I suspect it'll mishandle the just_wait_proc and wait_for_cell cases. We can add these conditions if needed, but I'd like to at least hear a description of such cases, if not to see an actual test case where it happens. > > (If we agree to install this, I will also add a prominent comment > > explaining why this is being done.) > > I have misgivings about this, to be honest. Maybe we should discuss the > comment first? Sure, no problem. But let's agree on the code first, since the comment obviously depends on that. > Adding more special cases and further complication is a severe problem, > but not quite as severe as the misbehavior in this special case (the > same is true for the other known bug in this same function). The least > we can do for future hackers is admit that we are almost certain the > code can be simplified significantly, and let them know how, but that > we've decided not to, for the time being. The case that started this discussion is a relatively rare and corner case: a process that exits without producing any output, input that's available immediately when this process starts, and a loop which calls sleep-for whose behavior for various kinds of input is not well documented (e.g., I could argue that it is valid for sleep-for to postpone everything in Emacs, and the only reason I won't do that is because the code clearly shows the original intent of reading output from subprocesses when read_kbd is zero). So a specialized, very localized change that doesn't otherwise touch the overall logic is in my book precisely the right solution. Code simplification is fine, except when the result works subtly differently from what we have now, and I explained why conflating the two thread_select calls into one, the way it was proposed, is problematic due to small differences in these two calls in the current code.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 22:36:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 17:36:57 2025 Received: from localhost ([127.0.0.1]:54393 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHrYG-0007D6-Q3 for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 17:36:57 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:51163) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHrYE-0007Cy-FI for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 17:36:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762641408; x=1762900608; bh=4/9M11J2rqWMANcKijPYkIiz666n1MOrXToxRk+rNrg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=uySJbubTNDMse7TPE+PxDLjSlCZlZowCZNmo6szdbSS2LNAVMwISKcyctQ9zgqbQd N/oNV8oL8JlSlJ2bRZDTPce81HXW1d/kZodi4iPgIE7DOX0nRA4Py6OW8PmZZUHe0I bCa4+HlyDYuHLj9i7RgFiTHxA7r6VMP+OvySBFv+sm9+FIToSk59tFswXiBNz+ixeX GtMmrtCFeAnUZtHQhXlUFE7GIpsEY+PQ9BPdanuAAquP+Nn62L6xQa9Elozl4jrEIK FlM93q0iUJ65/zmjj68PU9ogr84mZDKWiGMAHnVhAIX10TrqhPg0BAdCNFkE5p1BGh Yb3L5rjv4ZMeQ== Date: Sat, 08 Nov 2025 22:36:40 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87seeo5ez2.fsf@HIDDEN> In-Reply-To: <86v7jk5xfy.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> <87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN> <877bw07erh.fsf@HIDDEN> <86v7jk5xfy.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 787755dc6c8d159a2dc8ef6259abe2987cf878bc MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> Indeed. sleep-for, which ignores "keyboard" input, ignores "keyboard" >> >> input, which includes the inotify FD. >> > >> > As it should, IMO. The fact that it ignores inotify is not the >> > problem. >> >> I agree, of course. I was explaining how sleep-for and sit-for differ. > > OK. So the patch I propose is below. It is basically the second hunk Spencer, what do you think? Does this handle the wait_for_cell and just_wait cases correctly? > Another deviation from your patch is that I added read_kbd to the > condition, so as not to affect callers that we haven't considered. I suspect it'll mishandle the just_wait_proc and wait_for_cell cases. > (If we agree to install this, I will also add a prominent comment > explaining why this is being done.) I have misgivings about this, to be honest. Maybe we should discuss the comment first? Adding more special cases and further complication is a severe problem, but not quite as severe as the misbehavior in this special case (the same is true for the other known bug in this same function). The least we can do for future hackers is admit that we are almost certain the code can be simplified significantly, and let them know how, but that we've decided not to, for the time being. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 15:57:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 10:57:51 2025
Received: from localhost ([127.0.0.1]:52251 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHlK2-0000Ra-9y
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 10:57:50 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34308)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHlJz-0000RU-O7
for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 10:57:48 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHlJs-0004SS-Sv; Sat, 08 Nov 2025 10:57:40 -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=4MkQ4TFiVrKrlhR2frJHLzDdWPbAsg8YYmWbERZzvDw=; b=Zi8wsGfcKDyF
sCvvRgK8/uA2Yl3feI3uH54exD1AClJkVZM/LhiPpUlHtJBn4l/TkEi5u/kzhtRxbaB7sE6uU0GmJ
McMjzKuSft2yiSGikdsIkED5paoIDAYbz5U55stz/MK2MeoD64VIrcKFTWqHoZm2Lid8gsFUQXejB
pg9pZNewYc1WiIGyaGNlfUokPu+iM0Zi1BSXREflFoFWa6hKIEabqwyfNQA9oplEuSaggJ6Le1F/r
Kw1D0M43vUtRHWpUnhFB6/rphZ0eSgZ+43ssqHTeVewbrqHJ5JowYKYZNna0TMYjAgNxkDBp3VStm
yMt/7UOEY33dRc0xKJEVEw==;
Date: Sat, 08 Nov 2025 17:57:37 +0200
Message-Id: <86v7jk5xfy.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <877bw07erh.fsf@HIDDEN> (message from Pip Cet on Sat, 08
Nov 2025 14:58:17 +0000)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN>
<ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN>
<87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN>
<87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN>
<877bw07erh.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (---)
> Date: Sat, 08 Nov 2025 14:58:17 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN
>
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
> > If this is the reason, then we need to discuss whether the behavior is
> > correct. If one of the "keyboard" descriptors is ready for reading,
> > should the sentinels be run?
>
> Depends on whether we're actually going to attempt reading it.
>
> If the descriptor becomes ready and we're about to read it (the sit-for
> case), we should delay sentinels, since user input has priority.
>
> If the descriptor becomes ready but we're not about to read it anyway
> (the sleep-for case), we should ignore it, but we don't, so we delay the
> sentinel indefinitely.
More accurately, we do ignore it (in the sense that we don't read the
input), we just don't call the sentinels, as we would if no "keyboard"
input was available.
IOW, wait_reading_process_output, when called with read_kbd = 0, runs
sentinels only if there's no input ready to be read. If we could type
on the keyboard fast enough, we could have triggered the same behavior
without file notifications at all.
> > If not, then this problem reduces to the question
> > why we didn't consume the inotify input in this case.
>
> Because it's "keyboard" input, and we've been told to ignore "keyboard"
> input.
Which I think is correct. That's what the callers with read_kbd = 0
want.
> >> > Not AFAIU. The "input" that is constantly "ready" and prevents us
> >> > from running the sentinel has not been identified. Interestingly, if
> >>
> >> It's the inotify fd.
> >
> > And in the Windows case, where file notifications don't come through
> > pselect, what prevents the sentinel from running?
>
> File notifications are handled by sys_select on Windows, right?
>
> See w32proc.c:sys_select:
>
> for (i = 0; i < nfds; i++)
> if (FD_ISSET (i, &orfds) || FD_ISSET (i, &owfds))
> {
> if (i == 0)
> {
> if (keyboard_handle)
> {
> /* Handle stdin specially */
> wait_hnd[nh] = keyboard_handle;
> fdindex[nh] = i;
> nh++;
> }
>
> /* Check for any emacs-generated input in the queue since
> it won't be detected in the wait */
> if (rfds && detect_input_pending ())
> {
> FD_SET (i, rfds);
> return 1;
> }
> else if (noninteractive)
> {
> if (handle_file_notifications (NULL))
> return 1;
> }
> }
>
> IIUC, detect_input_pending would detect the pending notification, but we
> don't call it because FD 0, which sys_select does handle, is "keyboard"
> input, so FD_ISSET (0, &orfds) is false. Same as GNU/Linux, really,
> except that it's simulated in sys_select rather than actually done in
> the syscall.
>
> I don't know whether file notifications actually wake us up on Windows
> if we're in the select call, but that's not the issue here.
AFAIR, file notifications on MS-Windows do wake us up inside select
because of the call to detect_input_pending above.
> In our case, input is pending when we first call select, so the return
> value of the first select call is 1, then we call select again without
> FD 0, the return value is 0, and we infloop.
Yes, that's also my conclusion. So what wait_reading_process_output
sees is the same in the Windows case.
> >> Indeed. sleep-for, which ignores "keyboard" input, ignores "keyboard"
> >> input, which includes the inotify FD.
> >
> > As it should, IMO. The fact that it ignores inotify is not the
> > problem.
>
> I agree, of course. I was explaining how sleep-for and sit-for differ.
OK. So the patch I propose is below. It is basically the second hunk
of what you proposed. I don't want to risk breakage by removing the
first call to thread_select, because it does several things
differently: it handles the child_signal_read_fd differently, and it
ignores the read_kbd value, at the very least. That call to
thread_select is there to check for input available without delay, and
that because processing any kind of input is preferred to running
sentinels.
Another deviation from your patch is that I added read_kbd to the
condition, so as not to affect callers that we haven't considered.
(If we agree to install this, I will also add a prominent comment
explaining why this is being done.)
diff --git a/src/process.c b/src/process.c
index 86e83e5..8445246 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5844,6 +5844,11 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (nfds == 0)
{
+ if (!read_kbd && update_tick != process_tick)
+ {
+ got_some_output = status_notify (NULL, wait_proc);
+ if (do_display) redisplay_preserve_echo_area (113);
+ }
/* Exit the main loop if we've passed the requested timeout,
or have read some bytes from our wait_proc (either directly
in this call or indirectly through timers / process filters),
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 14:58:33 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 09:58:33 2025
Received: from localhost ([127.0.0.1]:51815 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHkOe-0006ZY-HU
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 09:58:33 -0500
Received: from mail-24416.protonmail.ch ([109.224.244.16]:18685)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHkOb-0006ZS-2Z
for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 09:58:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762613902; x=1762873102;
bh=FR7Nt7RjwJSh4uX/VLFFguIncCfMf8YWmZLEcidNJAE=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=kNAz2+9af8veLXWh7onUSB8ECzfoq1y6f2IQGspUl/gqMqoKNIs4RX7ZrkhtLJTb3
RA1awatapYaBpg8fEt09jhluaPG25IEF6mr93eQ2iZWBU2a5tHjGyHwm2NXjlZfR5V
MwH3ErbKTPgotRUQ2PeEQX8VstvvAyFaxfBN77vki0gPFCY46EtSKpq1qtLDNenQVc
VNGv9RR3PzM/YEmAQwy+dNnzhEv3ERwuLFk2RmRXeNEmlCa4alt9bw/WkqH+nMc4hN
WTSUeFuDN1QMhFrBR+kBY1eD1p7n4Cd7Ma9fpp4yexvaUhib7ehSURCERtCNF18z/w
z3RYpNdveB6wA==
Date: Sat, 08 Nov 2025 14:58:17 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <877bw07erh.fsf@HIDDEN>
In-Reply-To: <86bjlc7l75.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN>
<ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN>
<87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN>
<87a50w6f3a.fsf@HIDDEN> <86bjlc7l75.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: fc9fc882e994d1c0f52a83920ca232ac34c6b7e5
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Sat, 08 Nov 2025 09:36:31 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dm=
itry@HIDDEN
>>
>> >> There is no point in "going back" to investigation if there's already=
a
>> >> categorical veto on what seems very likely to be the best solution.
>> >
>> > The veto is because radical changes are proposed that I cannot
>> > possibly review and asses, given that the root cause is still unknown.
>>
>> Sorry, but it is not. It has been described clearly from the beginning,
>> and the only significant addition is the discovery that the inotify fd
>> counts as "keyboard" input because it uses add_read_fd rather than
>> add_non_keyboard_read_fd. This is consistent with its producing
>> kbd_buffer events but inconsistent with the expected behavior of
>> interrupting sleep-for.
>
> If this is the reason, then we need to discuss whether the behavior is
> correct. If one of the "keyboard" descriptors is ready for reading,
> should the sentinels be run?
Depends on whether we're actually going to attempt reading it.
If the descriptor becomes ready and we're about to read it (the sit-for
case), we should delay sentinels, since user input has priority.
If the descriptor becomes ready but we're not about to read it anyway
(the sleep-for case), we should ignore it, but we don't, so we delay the
sentinel indefinitely.
> If not, then this problem reduces to the question
> why we didn't consume the inotify input in this case.
Because it's "keyboard" input, and we've been told to ignore "keyboard"
input.
>> >> In any case, there is no mystery left here to be investigated, as far=
as
>> >> I know.
>> >>
>> >> Spencer described what happened clearly in the very first message, an=
d
>> >> we've confirmed it several times since.
>> >
>> > Not AFAIU. The "input" that is constantly "ready" and prevents us
>> > from running the sentinel has not been identified. Interestingly, if
>>
>> It's the inotify fd.
>
> And in the Windows case, where file notifications don't come through
> pselect, what prevents the sentinel from running?
File notifications are handled by sys_select on Windows, right?
See w32proc.c:sys_select:
for (i =3D 0; i < nfds; i++)
if (FD_ISSET (i, &orfds) || FD_ISSET (i, &owfds))
{
=09if (i =3D=3D 0)
=09 {
=09 if (keyboard_handle)
=09 {
=09=09/* Handle stdin specially */
=09=09wait_hnd[nh] =3D keyboard_handle;
=09=09fdindex[nh] =3D i;
=09=09nh++;
=09 }
=09 /* Check for any emacs-generated input in the queue since
=09 it won't be detected in the wait */
=09 if (rfds && detect_input_pending ())
=09 {
=09=09FD_SET (i, rfds);
=09=09return 1;
=09 }
=09 else if (noninteractive)
=09 {
=09=09if (handle_file_notifications (NULL))
=09=09 return 1;
=09 }
=09 }
IIUC, detect_input_pending would detect the pending notification, but we
don't call it because FD 0, which sys_select does handle, is "keyboard"
input, so FD_ISSET (0, &orfds) is false. Same as GNU/Linux, really,
except that it's simulated in sys_select rather than actually done in
the syscall.
I don't know whether file notifications actually wake us up on Windows
if we're in the select call, but that's not the issue here.
In our case, input is pending when we first call select, so the return
value of the first select call is 1, then we call select again without
FD 0, the return value is 0, and we infloop.
>> >> Which FDs are registered as keyboard FDs is a tangential issue.
>> >
>> > From where I stand, they are an important part of understanding the
>> > behavior. Because it could be that the original test case is not a
>> > bug at all, but the behavior we want (and the fact that there's an
>> > infloop just means there's a bug in the test case). Whether or not
>>
>> ... the original bug caused a busy infloop.
>
> So does this:
>
> (while t
> (sleep-for 1))
>
> but we don't consider that a bug, do we?
I meant "busy" as in 100% CPU (one core) usage.
>> > It is interesting because both sleep-for and sit-for call
>> > wait_reading_process_output, although in slightly different ways, and
>> > we need to understand why something that happens in one of these calls
>> > doesn't happen in the other.
>>
>> Indeed. sleep-for, which ignores "keyboard" input, ignores "keyboard"
>> input, which includes the inotify FD.
>
> As it should, IMO. The fact that it ignores inotify is not the
> problem.
I agree, of course. I was explaining how sleep-for and sit-for differ.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 12:39:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 07:39:25 2025
Received: from localhost ([127.0.0.1]:51316 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHiE0-00016h-Kf
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 07:39:25 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:34940)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHiDx-00016V-QS
for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 07:39:23 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHiDq-0002hw-Hd; Sat, 08 Nov 2025 07:39:15 -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=wJCrm3aDKDrUFy0SkJ9zlZdPoCkFzxsum9Q5luJ+/Go=; b=RToxwand1W7Q
oH24ntR/KUmtLKr7H4hbA1WWCSJvBCu9L/VJWeeYzvyvtU7i0mVLWbVSBiS7mFr8MjIbHLgyk3jOD
JEaf6CRA0xTIbAhWUmoo4Ebi9dtuIASHURnrYUFqNpAwgaGA4h/64cRD6DVc7X1icyQNQAWAPpxtu
lSVkwIT1yMOfuNGf9ZJkPt5UCfINAWPWCYU8vTk7Zd7UejIUV2vSFtI8RpEDoCfggRQnHJ9b5TLeC
qS8f/VYwpD5djpODSwDVJvKSe8qjbANK8rqTfQN+eGbyFitByKNMUF923mL6jiQOVNiBAiY1u6QwO
q8zOH1x2oCmBL+H6JUpmnw==;
Date: Sat, 08 Nov 2025 14:39:10 +0200
Message-Id: <86bjlc7l75.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87a50w6f3a.fsf@HIDDEN> (message from Pip Cet on Sat, 08
Nov 2025 09:36:31 +0000)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN>
<87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN>
<ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN>
<87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN>
<87a50w6f3a.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (---)
> Date: Sat, 08 Nov 2025 09:36:31 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN
>
> >> There is no point in "going back" to investigation if there's already a
> >> categorical veto on what seems very likely to be the best solution.
> >
> > The veto is because radical changes are proposed that I cannot
> > possibly review and asses, given that the root cause is still unknown.
>
> Sorry, but it is not. It has been described clearly from the beginning,
> and the only significant addition is the discovery that the inotify fd
> counts as "keyboard" input because it uses add_read_fd rather than
> add_non_keyboard_read_fd. This is consistent with its producing
> kbd_buffer events but inconsistent with the expected behavior of
> interrupting sleep-for.
If this is the reason, then we need to discuss whether the behavior is
correct. If one of the "keyboard" descriptors is ready for reading,
should the sentinels be run? If yes, why yes? If not, then this
problem reduces to the question why we didn't consume the inotify
input in this case.
> > When the root cause becomes known and understood, and the change I
> > vetoed is indeed the best one, I could change my mind.
>
> So your veto isn't a veto.
It is, as long as the problem is described in phenomenological terms,
and does not include the root cause and what to do about it.
> >> In any case, there is no mystery left here to be investigated, as far as
> >> I know.
> >>
> >> Spencer described what happened clearly in the very first message, and
> >> we've confirmed it several times since.
> >
> > Not AFAIU. The "input" that is constantly "ready" and prevents us
> > from running the sentinel has not been identified. Interestingly, if
>
> It's the inotify fd.
And in the Windows case, where file notifications don't come through
pselect, what prevents the sentinel from running?
> >> Which FDs are registered as keyboard FDs is a tangential issue.
> >
> > From where I stand, they are an important part of understanding the
> > behavior. Because it could be that the original test case is not a
> > bug at all, but the behavior we want (and the fact that there's an
> > infloop just means there's a bug in the test case). Whether or not
>
> ... the original bug caused a busy infloop.
So does this:
(while t
(sleep-for 1))
but we don't consider that a bug, do we?
IOW, not every infloop is necessarily a bug in Emacs.
> > It is interesting because both sleep-for and sit-for call
> > wait_reading_process_output, although in slightly different ways, and
> > we need to understand why something that happens in one of these calls
> > doesn't happen in the other.
>
> Indeed. sleep-for, which ignores "keyboard" input, ignores "keyboard"
> input, which includes the inotify FD.
As it should, IMO. The fact that it ignores inotify is not the
problem.
> > If the above still doesn't convince, then I will have to investigate
> > these issues myself, in which case please wait for me to find time to
> > do that, and let's take it from there, after I describe my findings.
>
> If you think there are specific open questions, please ask them. I'm not
> aware of any remaining ones.
See above.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 09:36:48 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 04:36:48 2025 Received: from localhost ([127.0.0.1]:50689 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHfNH-0004wT-Hi for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 04:36:48 -0500 Received: from mail-24418.protonmail.ch ([109.224.244.18]:63447) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHfND-0004w0-EY for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 04:36:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762594595; x=1762853795; bh=wLwQ9Su8qgAXbWYFDosuKTFlaNnuOJKxgyC/GZQJPEQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=qsRly8AV2iuAWIbLub5UVnhI5UnwBTtn7Em750Ln+4w+pu/JuPlSQNCFMQnH3jC83 laSKfBMX7cAsziSAbW5tcRn/M7jlesYq+Iqf+AeaAB+SujLViEeDah7Et10TpGnSNT qtvFzL7z1PMD3g/qyDwfn/JP5Eu+tLoF2Fg+5aBQoSWcj+vbAOxLhOaEfDcel0HOq+ +NW4sp0ArXXF8YvNml/kohCiv2IwLdfUsVBhpmGjF0btj2/LphGtghH+dy5MXdLf5R vVe8/h6c303IUZx2guropMbVBAo9wp+KhBv8Z6BQJWR9nOPUYfV7AWgVDE2jR9sd2s 1MYd7nU5Ha0nA== Date: Sat, 08 Nov 2025 09:36:31 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87a50w6f3a.fsf@HIDDEN> In-Reply-To: <86cy5s99ji.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> <86cy5s99ji.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4626d5f4a4110cc2af65c3a57e5ba90149d7a90f MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Sat, 08 Nov 2025 08:30:14 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: Spencer Baugh <sbaugh@HIDDEN>, 79777 <at> debbugs.gnu.org, eggert= @cs.ucla.edu, dmitry@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> > Once again, until we have a full understanding of what "keyboard >> > input" prevents the sentinel from running in the original script, we >> > are not ready to seriously discuss any fixes, let alone such radical >> > changes in the code which remained basically unaltered for decades. >> >> I agree that we should understand that issue, and probably rename >> add_read_fd so it's only used for actual keyboard/mouse input. >> >> However, I'm pretty sure Spencer understands that, too, and that he took >> it into account when suggesting the fix that I had included (not >> proposed) should be applied after testing, which includes turning our >> reproducer into a reliable testsuite test. > > How can an unknown cause be taken into account? Well, I don't know whether it's unknown to Spencer. I'm pretty sure that Spencer understands the code, and the cause. >> > So let's please go back to investigating the root cause of the >> > behavior we see here: why the sentinel isn't run, and >> >> There is no point in "going back" to investigation if there's already a >> categorical veto on what seems very likely to be the best solution. > > The veto is because radical changes are proposed that I cannot > possibly review and asses, given that the root cause is still unknown. Sorry, but it is not. It has been described clearly from the beginning, and the only significant addition is the discovery that the inotify fd counts as "keyboard" input because it uses add_read_fd rather than add_non_keyboard_read_fd. This is consistent with its producing kbd_buffer events but inconsistent with the expected behavior of interrupting sleep-for. > When the root cause becomes known and understood, and the change I > vetoed is indeed the best one, I could change my mind. So your veto isn't a veto. >> In any case, there is no mystery left here to be investigated, as far as >> I know. >> >> Spencer described what happened clearly in the very first message, and >> we've confirmed it several times since. > > Not AFAIU. The "input" that is constantly "ready" and prevents us > from running the sentinel has not been identified. Interestingly, if It's the inotify fd. > I interrupt the loop with C-g, the file notification is shown only > after the sentinel message. Which means the inotify descriptor is > also not being read before the loop ends -- why is that? Because the inotify fd is "keyboard" input. >> Which FDs are registered as keyboard FDs is a tangential issue. > > From where I stand, they are an important part of understanding the > behavior. Because it could be that the original test case is not a > bug at all, but the behavior we want (and the fact that there's an > infloop just means there's a bug in the test case). Whether or not ... the original bug caused a busy infloop. That's definitely a bug. > this is the case can only be decided when we understand which > descriptors are at play here, and how and why they prevent the > sentinel from running. The inotify fd. It's "keyboard" input. So it gets ignored by the second select call, but not the first one (which zaps the timeout). >> >=C2=A0 why adding a single sit-for lets it run and avoids the loop? >> >> If you're referring to this: >> >> > And if I insert (sit-for 1) before the while loop, it doesn't hang at >> > all -- again, why? >> >> That's because everything then happens in a sit-for, which doesn't >> ignore "keyboard" input, so the sentinel runs. I don't see why this is >> interesting. > > It is interesting because both sleep-for and sit-for call > wait_reading_process_output, although in slightly different ways, and > we need to understand why something that happens in one of these calls > doesn't happen in the other. Indeed. sleep-for, which ignores "keyboard" input, ignores "keyboard" input, which includes the inotify FD. > If the above still doesn't convince, then I will have to investigate > these issues myself, in which case please wait for me to find time to > do that, and let's take it from there, after I describe my findings. If you think there are specific open questions, please ask them. I'm not aware of any remaining ones. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 09:08:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 04:08:16 2025 Received: from localhost ([127.0.0.1]:50612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHevf-0003f3-KH for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 04:08:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38914) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHevc-0003ex-Pn for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 04:08:13 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHevV-00032U-Tt; Sat, 08 Nov 2025 04:08:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=JDcgyFz1+2LKyIci+GXb0llwfRuBIyClWBDwVNjjl6M=; b=SQcdemMFvf1pI3WRl5Tv ceELX/XN4V8BYWV5oJS7jD9uksoHCyd6g+k3AMO3u+fh+6tU3SRckqx4QA6VN5PricuR5K7S+rpud oGgWV5stut+GmHct2xmHwHCKbRK4kOm1vFg4pYwpNTSj5J31n/s4NnqbhCFyZoVKeH5oY+FWwIq0D N1AsjYDUTNn0JtCdHIOYMsgZwaYhLRg8X1kMUWUp6sF3Q0wf4Woec8nC0JzdWhGlt72KcqwKmny/8 7HaSip6Z+JmDXUhRabOV5w4mZu1g+5zU1Na3xPSatFyqMB3hMn/pegDQydZ5cfZbNe8wPido5WEBZ W/moR750TYBHXA==; Date: Sat, 08 Nov 2025 11:08:01 +0200 Message-Id: <86cy5s99ji.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87qzu9x6y7.fsf@HIDDEN> (message from Pip Cet on Sat, 08 Nov 2025 08:30:14 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> <87qzu9x6y7.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (---) > Date: Sat, 08 Nov 2025 08:30:14 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Spencer Baugh <sbaugh@HIDDEN>, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > Once again, until we have a full understanding of what "keyboard > > input" prevents the sentinel from running in the original script, we > > are not ready to seriously discuss any fixes, let alone such radical > > changes in the code which remained basically unaltered for decades. > > I agree that we should understand that issue, and probably rename > add_read_fd so it's only used for actual keyboard/mouse input. > > However, I'm pretty sure Spencer understands that, too, and that he took > it into account when suggesting the fix that I had included (not > proposed) should be applied after testing, which includes turning our > reproducer into a reliable testsuite test. How can an unknown cause be taken into account? > > So let's please go back to investigating the root cause of the > > behavior we see here: why the sentinel isn't run, and > > There is no point in "going back" to investigation if there's already a > categorical veto on what seems very likely to be the best solution. The veto is because radical changes are proposed that I cannot possibly review and asses, given that the root cause is still unknown. When the root cause becomes known and understood, and the change I vetoed is indeed the best one, I could change my mind. > In any case, there is no mystery left here to be investigated, as far as > I know. > > Spencer described what happened clearly in the very first message, and > we've confirmed it several times since. Not AFAIU. The "input" that is constantly "ready" and prevents us from running the sentinel has not been identified. Interestingly, if I interrupt the loop with C-g, the file notification is shown only after the sentinel message. Which means the inotify descriptor is also not being read before the loop ends -- why is that? > Which FDs are registered as keyboard FDs is a tangential issue. From where I stand, they are an important part of understanding the behavior. Because it could be that the original test case is not a bug at all, but the behavior we want (and the fact that there's an infloop just means there's a bug in the test case). Whether or not this is the case can only be decided when we understand which descriptors are at play here, and how and why they prevent the sentinel from running. > >Â why adding a single sit-for lets it run and avoids the loop? > > If you're referring to this: > > > And if I insert (sit-for 1) before the while loop, it doesn't hang at > > all -- again, why? > > That's because everything then happens in a sit-for, which doesn't > ignore "keyboard" input, so the sentinel runs. I don't see why this is > interesting. It is interesting because both sleep-for and sit-for call wait_reading_process_output, although in slightly different ways, and we need to understand why something that happens in one of these calls doesn't happen in the other. If the above still doesn't convince, then I will have to investigate these issues myself, in which case please wait for me to find time to do that, and let's take it from there, after I describe my findings.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 08:30:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:30:31 2025 Received: from localhost ([127.0.0.1]:50535 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHeL9-0002KH-9e for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:30:31 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:18171) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHeL6-0002Jx-0J for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:30:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762590621; x=1762849821; bh=W3gsnj0SAZoM1MLiLqstqlCL1uF8+ja8d6RcR0qiXRE=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=JEnx7qhMJDXJHH1CE0haZff+q9tSsGiJ3jSaaQgfnNONa/MpU5+9a7+j4bWUWg9pm wURz8Rlv1hYPpJLf9kV+PghsrDhY7gF8c1ZBuLVkldCB0mrM9clVWrgKmFn2XG9img 2NkpuAdGvzlTUG7iZLO/DHiHfICKSQIITvo+2GdkrMj+AtzjlnFaJlJbESOj6J8nQA 6eXnhTizl3nI1aeuoiglGKMZ9/QBawF3GdJWjSDnlSD09DDmg3GhHMITSLVsn6VBE1 hfejnYbZRWgg/Lq0DIh/D+mVZWkp7zmlrX4dgxlbRkSc+/5cCgsa7BVniqNWH0Gjbi fh/RZfiNJ1RYA== Date: Sat, 08 Nov 2025 08:30:14 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87qzu9x6y7.fsf@HIDDEN> In-Reply-To: <86seep7zym.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> <86seep7zym.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1164f0b22734cdd95c5875bc81245cd17919061a MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: Spencer Baugh <sbaugh@HIDDEN>, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: Pip Cet <pipcet@HIDDEN>, 79777 <at> debbugs.gnu.org, >> eggert@HIDDEN, dmitry@HIDDEN >> Date: Fri, 07 Nov 2025 12:15:22 -0500 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> Date: Fri, 07 Nov 2025 16:05:25 +0000 >> >> From: Pip Cet <pipcet@HIDDEN> >> >> Cc: Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN, 79777@de= bbugs.gnu.org, eggert@HIDDEN >> >> >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> >> >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, >> >> >> Paul Eggert <eggert@HIDDEN> >> >> >> Date: Fri, 07 Nov 2025 10:18:47 -0500 >> >> >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> >> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> >> >> >> >> >> That change looks harmless, but I think it indicates something= else in >> >> >> >> the code is incorrect. >> >> >> > >> >> >> > I think the whole approach of using two select calls is very fra= gile. >> >> >> >> >> >> Agreed, I think that's the root of the problem. I have previously= found >> >> >> other bugs related to this update_tick select call, so I do think = it's >> >> >> time to just get rid of it. >> >> > >> >> > It's a non-starter for me, so please don't propose changes that rem= ove >> >> > the first call to thread_select. >> >> >> >> Can you provide a reason for that? The first call clearly seems to be >> >> unnecessary and harmful. >> > >> > I simply don't trust this conclusion. That call was there for >> > decades, so we should have some minimal respect to those who wrote it >> > and those who used it for all those years: they generally knew what >> > they were doing. By contrast, we have been looking at this code for >> > the whole of half a day. Really, a bit of modesty is called for. >> >> I've been looking at this specific code for months, and I've come to >> this conclusion only after multiple other bugs with this specific code. >> >> I have great respect for those who wrote this code originally. The >> original version was simple and elegant. It wasn't buggy then, but it >> has become buggy over the years with the addition of many other changes >> to Emacs. And with those other changes all considered together, I think >> the design of calling select twice simply no longer works. > > Once again, until we have a full understanding of what "keyboard > input" prevents the sentinel from running in the original script, we > are not ready to seriously discuss any fixes, let alone such radical > changes in the code which remained basically unaltered for decades. I agree that we should understand that issue, and probably rename add_read_fd so it's only used for actual keyboard/mouse input. However, I'm pretty sure Spencer understands that, too, and that he took it into account when suggesting the fix that I had included (not proposed) should be applied after testing, which includes turning our reproducer into a reliable testsuite test. > So let's please go back to investigating the root cause of the > behavior we see here: why the sentinel isn't run, and There is no point in "going back" to investigation if there's already a categorical veto on what seems very likely to be the best solution. In any case, there is no mystery left here to be investigated, as far as I know. Spencer described what happened clearly in the very first message, and we've confirmed it several times since. Which FDs are registered as keyboard FDs is a tangential issue. >=C2=A0 why adding a single sit-for lets it run and avoids the loop? If you're referring to this: > And if I insert (sit-for 1) before the while loop, it doesn't hang at > all -- again, why? That's because everything then happens in a sit-for, which doesn't ignore "keyboard" input, so the sentinel runs. I don't see why this is interesting. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 08:25:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 03:25:52 2025 Received: from localhost ([127.0.0.1]:50511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHeGe-0001xz-5E for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:25:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49542) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHeGb-0001xK-OC for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 03:25:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHeGU-0003A5-4Q; Sat, 08 Nov 2025 03:25:43 -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=QxswXMrRnfVScw5CGjpd26VEQh/8ZltC/htzpUUD8Io=; b=ejbEeeb1oU0u QmOjehYwrUSdAHb/VDISd0MdSeSbFrvKtd0rv+dpGO5xc6cr+tFZNaZbnFFIvWhRt7G6mV3vCDKTk GnWoDAzATnmw/neWOkT1lqsaOgxxeUYYr/qjUdRvqcirqxennasFZOhsY9Yh9ZWFjW8aj2JZV3jKR +DZPv/lY94H9rFGpy3ODC44eyH3F+vGNDZmNNMZYS5iCVoZ7ypWDCUYU9cRJvIRgK/D+asKUMBs/P I8PCYBG3KyOcsSpp04WaJ5o3eCxZRimWkdCP5PSoaXk7pjDn+KfxEAX+iC7g8zpEDFQg4LbrSvyE/ ueqbel17Nvix5tWfFMgIsQ==; Date: Sat, 08 Nov 2025 10:25:38 +0200 Message-Id: <86ldkh7wxp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Paul Eggert <eggert@HIDDEN> In-Reply-To: <e59a0521-0b7c-40a8-a8e5-fbacf40c2b97@HIDDEN> (message from Paul Eggert on Fri, 7 Nov 2025 20:22:11 -0800) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> <e59a0521-0b7c-40a8-a8e5-fbacf40c2b97@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, pipcet@HIDDEN, dmitry@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 (---) > Date: Fri, 7 Nov 2025 20:22:11 -0800 > Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, > Pip Cet <pipcet@HIDDEN> > From: Paul Eggert <eggert@HIDDEN> > > On 2025-11-07 08:51, Eli Zaretskii wrote: > > That call was there for > > decades, so we should have some minimal respect to those who wrote it > > and those who used it for all those years: they generally knew what > > they were doing. By contrast, we have been looking at this code for > > the whole of half a day. > > This suggestion runs counter to my experience. Although we old-timers > generally knew what we were doing, we were so busy that we would spend > much less than even half a day worrying about this kind of code. > Also, to be frank we *knew* less than experts do nowadays. > > Plus, most of us old-timers are no longer available to fix or even > answer questions about our mistakes, whereas the new experts are more > available to fix things. > > Although it's not always an easy call when code is this involved, there > are real advantages to taking fixes from active developers who know what > they're doing and are willing to make further improvements as needed. > Among other things, it furthers a culture of encouraging contributions. All true, but: . whatever mistakes the "old-timers" made, they have withstood the test of time by many users using that for decades; and . most importantly, we still don't have a complete enough understanding of what prevents the sentinel from running in the original recipe, but not in minor and seemingly-insignificant variations thereof, so we cannot yet claim that we "know what we are doing"
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 07:30:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 02:30:38 2025
Received: from localhost ([127.0.0.1]:50422 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHdPC-0008JO-7q
for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 02:30:38 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:60370)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHdP6-0008Id-HK
for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 02:30:35 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHdP0-00075e-5n; Sat, 08 Nov 2025 02:30:26 -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=l6YSgSEa2GRGjadeapVff5V929uEhvdRPPM7tRCxZUk=; b=L1CiQm7OFtGL
z45SUBmafCjIbxzwK1X18a2gsTBm3aRpYjv9OistfHo3gzm6A/YkyorusS2hbxfB+eLu2Q6qoaB+C
nLruh6JOiVp2DbKfwqXJEQj9rREXpBo3cXxkphvcmitP5o1ditHp5KPEHT5xmv2RMOa8mHsXxIT6a
H+oH1bQORIra7pMoVWb4eg5HdxQ/Bzz5MUtPhhusTrKYMeniahwLovTaIeNSBJIAwN1Owgv6U3seA
MXQXXwLIwmCAoWKd2ue0EOAoiFUuhJhtoMSK+wmGHrJp1AtT4NcQquuqkCYhkYySAQ6h5chlPpZPy
ZT1EPYGl+ljHE0OvpEoWig==;
Date: Sat, 08 Nov 2025 09:30:22 +0200
Message-Id: <86pl9t7zht.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <87cy5t20ss.fsf@HIDDEN> (message from Pip Cet on Fri, 07
Nov 2025 17:46:34 +0000)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
<87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN>
<865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN>
<861pm9air8.fsf@HIDDEN> <87cy5t20ss.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (---)
> Date: Fri, 07 Nov 2025 17:46:34 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN
>
> "Eli Zaretskii" <eliz@HIDDEN> writes:
>
> >> > It's a non-starter for me, so please don't propose changes that remove
> >> > the first call to thread_select.
> >>
> >> Can you provide a reason for that? The first call clearly seems to be
> >> unnecessary and harmful.
> >
> > I simply don't trust this conclusion.
>
> Then provide evidence against it. I still haven't heard anything I can
> accept as a reason.
We still don't understand the root cause of the behavior, i.e. which
"available input" prevents the sentinel from being run. How can we
trust such conclusions when we don't understand the problem??
> > That call was there for decades, so we should have some minimal
> > respect to those who wrote it and those who used it for all those
> > years: they generally knew what they were doing. By contrast, we have
> > been looking at this code for the whole of half a day. Really, a bit
> > of modesty is called for.
>
> I cannot speak for Spencer, but I resent the implication that I lack
> respect ("minimal", at that) or ("a bit of") modesty, or any speculation
> on how much time I've been looking at this code for.
Then let's behave accordingly, and in particular refrain from
suggesting radical solutions before we have a full understanding of
the problem.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 07:20:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Nov 08 02:20:31 2025 Received: from localhost ([127.0.0.1]:50404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHdFP-0007qy-19 for submit <at> debbugs.gnu.org; Sat, 08 Nov 2025 02:20:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51580) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHdFL-0007qq-75 for 79777 <at> debbugs.gnu.org; Sat, 08 Nov 2025 02:20:28 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHdFE-0002iE-MM; Sat, 08 Nov 2025 02:20:20 -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=k+HgtS8dyFUmZsQXMjFxGoeNK80+hNjDcAc7EbxhpAY=; b=rsyPWUvd6Fub OieO0UI+fcgYkY9WYStlYVRrorYdo+LLVFrfYWj91d6PqokqK06ONMfqQy0vldY3vqpIOxMHsvBDA fwndovnq3C2tGt7m/34uY78yvUvJPKzSAPSwqMiMIiivWfP+gZ4DHhKYZBs2vIMn5r4hQqeE4e0YB cnGaBD70+Dtzq+ojd1hxqp2CjmEL1aM0GSEOnS3zl1iwabtQBWgjGnS4YEfpo9iqD/FHAq4lT3rHf dC7YBFd8cglarZbbrf8orFUOZC3Y4MMvMEHSw9tVpf2tls88tJG2IM9kv/C8Gz/L5J+9WArbxGPjh pCYMAOg36huzDZsrtaOHPg==; Date: Sat, 08 Nov 2025 09:20:17 +0200 Message-Id: <86seep7zym.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier5xbl69xx.fsf@HIDDEN> (message from Spencer Baugh on Fri, 07 Nov 2025 12:15:22 -0500) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> <ier5xbl69xx.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, pipcet@HIDDEN, eggert@HIDDEN, 79777 <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: Spencer Baugh <sbaugh@HIDDEN> > Cc: Pip Cet <pipcet@HIDDEN>, 79777 <at> debbugs.gnu.org, > eggert@HIDDEN, dmitry@HIDDEN > Date: Fri, 07 Nov 2025 12:15:22 -0500 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Date: Fri, 07 Nov 2025 16:05:25 +0000 > >> From: Pip Cet <pipcet@HIDDEN> > >> Cc: Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN > >> > >> "Eli Zaretskii" <eliz@HIDDEN> writes: > >> > >> >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, > >> >> Paul Eggert <eggert@HIDDEN> > >> >> Date: Fri, 07 Nov 2025 10:18:47 -0500 > >> >> From: Spencer Baugh via "Bug reports for GNU Emacs, > >> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > >> >> > >> >> >> That change looks harmless, but I think it indicates something else in > >> >> >> the code is incorrect. > >> >> > > >> >> > I think the whole approach of using two select calls is very fragile. > >> >> > >> >> Agreed, I think that's the root of the problem. I have previously found > >> >> other bugs related to this update_tick select call, so I do think it's > >> >> time to just get rid of it. > >> > > >> > It's a non-starter for me, so please don't propose changes that remove > >> > the first call to thread_select. > >> > >> Can you provide a reason for that? The first call clearly seems to be > >> unnecessary and harmful. > > > > I simply don't trust this conclusion. That call was there for > > decades, so we should have some minimal respect to those who wrote it > > and those who used it for all those years: they generally knew what > > they were doing. By contrast, we have been looking at this code for > > the whole of half a day. Really, a bit of modesty is called for. > > I've been looking at this specific code for months, and I've come to > this conclusion only after multiple other bugs with this specific code. > > I have great respect for those who wrote this code originally. The > original version was simple and elegant. It wasn't buggy then, but it > has become buggy over the years with the addition of many other changes > to Emacs. And with those other changes all considered together, I think > the design of calling select twice simply no longer works. Once again, until we have a full understanding of what "keyboard input" prevents the sentinel from running in the original script, we are not ready to seriously discuss any fixes, let alone such radical changes in the code which remained basically unaltered for decades. So let's please go back to investigating the root cause of the behavior we see here: why the sentinel isn't run, and why adding a single sit-for lets it run and avoids the loop?
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 8 Nov 2025 04:22:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 23:22:21 2025 Received: from localhost ([127.0.0.1]:50141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHaSz-0000X9-0m for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 23:22:21 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:47240) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eggert@HIDDEN>) id 1vHaSw-0000Wz-CA for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 23:22:19 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 2EF9A3C01084A; Fri, 7 Nov 2025 20:22:12 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id vr9qOA9zNQjv; Fri, 7 Nov 2025 20:22:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 020103C0149F3; Fri, 7 Nov 2025 20:22:12 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 020103C0149F3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1762575732; bh=O+P/N2bAmGhz50jv/9HGP2VGovoNo7IXq1gFQvXdvnA=; h=Message-ID:Date:MIME-Version:To:From; b=ofdNmkgwUMCnLy7X8/IxpY99wi4nG5DyYCk/yrtmYLiLMOzchSWMu51yRhkwjtHrO CMkHp33UzZBBVxtP1ndUj16ew5dh495Pz+JAaa9UBFG9BfmnzaROWjbcqgt8kF+ymT I9mlFrdElLzfpvWN1unM+NNN2aBV8HRe7lhdna0LftF97zNG7GTn5r0SKdmMwoh9UY 2Cx39fr10o1Kas4xI4iNW/C5RD06use8zoFrPI2Ms2E7DfATk83Gq51iqVWoCt0PWP X/MfWJFFEarJ70qYG8zjCRaARl18+eqr1WhNu9a1v0Hn5i3GxzAzGMj83ZrrGsos8P t7QJVAyzN1NKg== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id B4T9lb21kv14; Fri, 7 Nov 2025 20:22:11 -0800 (PST) Received: from penguin.cs.ucla.edu (47-154-25-30.fdr01.snmn.ca.ip.frontiernet.net [47.154.25.30]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id CFD6F3C01084A; Fri, 7 Nov 2025 20:22:11 -0800 (PST) Message-ID: <e59a0521-0b7c-40a8-a8e5-fbacf40c2b97@HIDDEN> Date: Fri, 7 Nov 2025 20:22:11 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever To: Eli Zaretskii <eliz@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> Content-Language: en-US From: Paul Eggert <eggert@HIDDEN> Organization: UCLA Computer Science Department In-Reply-To: <861pm9air8.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, dmitry@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 (-) On 2025-11-07 08:51, Eli Zaretskii wrote: > That call was there for > decades, so we should have some minimal respect to those who wrote it > and those who used it for all those years: they generally knew what > they were doing. By contrast, we have been looking at this code for > the whole of half a day. This suggestion runs counter to my experience. Although we old-timers generally knew what we were doing, we were so busy that we would spend much less than even half a day worrying about this kind of code. Also, to be frank we *knew* less than experts do nowadays. Plus, most of us old-timers are no longer available to fix or even answer questions about our mistakes, whereas the new experts are more available to fix things. Although it's not always an easy call when code is this involved, there are real advantages to taking fixes from active developers who know what they're doing and are willing to make further improvements as needed. Among other things, it furthers a culture of encouraging contributions.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 17:46:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 12:46:50 2025
Received: from localhost ([127.0.0.1]:47318 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHQXy-0007CU-3R
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:46:50 -0500
Received: from mail-4322.protonmail.ch ([185.70.43.22]:48269)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHQXu-0007CI-PY
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:46:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762537600; x=1762796800;
bh=3msKi8sfI0LgLv2QFsRZeQ2XePdfqj/JmuWOzyzuUuE=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=SIlfiKRWHHz+7bwe+TqlNHLCBn5AEVKB43j/zGhTcw7QKpY0SqRYjMcbFa4dyck+m
a+rw5GSVu5ZFvXdBm7qx6evMj/14B+qiIB6Dx9h6rWL4XJdgZEmKa0TMJr15m4Q2TX
rbe0Kf7VN4ixtCmBW4T42el9Y3xlLk5rZYKMf68DQDgtISDw1URzmooOTtZvNGdV18
E1lQl31Xm8w9EzLqcwh6ZKSBjgknUXNH2xXxM0X12wKUcJnjVCtO1Up/ItUGmU8azA
KzxFAGvJiOWgwCoAuG1H4o+Z7ksNnpwhWoSVXFzXY6EIDJJvmQHH1cRSb9Vvbi8+hG
t0IbeCqgb7RpQ==
Date: Fri, 07 Nov 2025 17:46:34 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87cy5t20ss.fsf@HIDDEN>
In-Reply-To: <861pm9air8.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
<87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN>
<865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN>
<861pm9air8.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 54d6e8c176ef09afe5f78c22728b78d9005d33dd
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Fri, 07 Nov 2025 16:05:25 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN, 79777@debbu=
gs.gnu.org, eggert@HIDDEN
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
>> >> Paul Eggert <eggert@HIDDEN>
>> >> Date: Fri, 07 Nov 2025 10:18:47 -0500
>> >> From: Spencer Baugh via "Bug reports for GNU Emacs,
>> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>> >>
>> >> >> That change looks harmless, but I think it indicates something el=
se in
>> >> >> the code is incorrect.
>> >> >
>> >> > I think the whole approach of using two select calls is very fragil=
e.
>> >>
>> >> Agreed, I think that's the root of the problem. I have previously fo=
und
>> >> other bugs related to this update_tick select call, so I do think it'=
s
>> >> time to just get rid of it.
>> >
>> > It's a non-starter for me, so please don't propose changes that remove
>> > the first call to thread_select.
>>
>> Can you provide a reason for that? The first call clearly seems to be
>> unnecessary and harmful.
>
> I simply don't trust this conclusion.
Then provide evidence against it. I still haven't heard anything I can
accept as a reason.
> That call was there for decades, so we should have some minimal
> respect to those who wrote it and those who used it for all those
> years: they generally knew what they were doing. By contrast, we have
> been looking at this code for the whole of half a day. Really, a bit
> of modesty is called for.
I cannot speak for Spencer, but I resent the implication that I lack
respect ("minimal", at that) or ("a bit of") modesty, or any speculation
on how much time I've been looking at this code for.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 17:15:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 12:15:32 2025 Received: from localhost ([127.0.0.1]:47101 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHQ3f-0005r0-MF for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:15:32 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33029) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vHQ3b-0005pA-Kh for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 12:15:30 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever In-Reply-To: <861pm9air8.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 07 Nov 2025 18:51:23 +0200") References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> <861pm9air8.fsf@HIDDEN> Date: Fri, 07 Nov 2025 12:15:22 -0500 Message-ID: <ier5xbl69xx.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1762535722; bh=h90oInh4ckKttG1IBGLflWiyofX+gdwXhLZx9SRm6nk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=EdsM+YbVIF8dQZ0I807iAprBZpulDCXXgpjf17JVk/1XmAs5N8EJJyaP3LjdEePYC 7St+vE2j4b0mWIHKmszFZsm0EyuMTyAc+Cbq5Aq54MJBdzWLy5kp0tMYnjN8dbEHnb xlyZ8x43mnywxQt5a8QbzuG6HDLyCvaVRRACqnN36helzbMz6KOmVk09e/IRQztkVI VLceeD/+12EbK+NIM4ZWW6eJP488vgIjaoJkaI9w0tB+uU+1RiDfHCl5ufwwSpVBPX oK9+/+1qKzUdvUIQE00KCiIfLrRQwFENJDv1gJzKOxqAUsUlqYmEGsk9/kCjLUZC70 1kmx0B3s5j2sg== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, Pip Cet <pipcet@HIDDEN>, eggert@HIDDEN, 79777 <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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 16:05:25 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, >> >> Paul Eggert <eggert@HIDDEN> >> >> Date: Fri, 07 Nov 2025 10:18:47 -0500 >> >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> >> >> >> That change looks harmless, but I think it indicates something else in >> >> >> the code is incorrect. >> >> > >> >> > I think the whole approach of using two select calls is very fragile. >> >> >> >> Agreed, I think that's the root of the problem. I have previously found >> >> other bugs related to this update_tick select call, so I do think it's >> >> time to just get rid of it. >> > >> > It's a non-starter for me, so please don't propose changes that remove >> > the first call to thread_select. >> >> Can you provide a reason for that? The first call clearly seems to be >> unnecessary and harmful. > > I simply don't trust this conclusion. That call was there for > decades, so we should have some minimal respect to those who wrote it > and those who used it for all those years: they generally knew what > they were doing. By contrast, we have been looking at this code for > the whole of half a day. Really, a bit of modesty is called for. I've been looking at this specific code for months, and I've come to this conclusion only after multiple other bugs with this specific code. I have great respect for those who wrote this code originally. The original version was simple and elegant. It wasn't buggy then, but it has become buggy over the years with the addition of many other changes to Emacs. And with those other changes all considered together, I think the design of calling select twice simply no longer works.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:58:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:58:13 2025 Received: from localhost ([127.0.0.1]:46986 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHPmu-0005EJ-Jl for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:58:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56758) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHPmr-0005EB-Su for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:58:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHPmk-0001NH-Pm; Fri, 07 Nov 2025 11:58:02 -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=2TOvH9HURIZvjVqYBkT9wS1c8w3DeRGgZS0Dyhq3k1o=; b=JYvL9HtISr7e DR52VKYp86oWvVQhW6+jqz1ScPfu+lquyOD4lyHE63QNEbT2nSVviEppFrAoVJ5g/NW0Lfbfv01PF PZNCFj1EkQ6++JocszOd1s3twmZVyNFtJOzBPGk4fV6FJK6Mvg2w3RHjV6sXGZWntjfGZ36IcfKPR UG7waD+wLr1bptMSOc+7F2UreObAVK9ZjQxmE7NRskSGYaUXXVyMSPv0hyEHKCy8Ndl+8nkufK12k 5QB2GTWeDE+Jc3QZm2FSWyFQxbTcPf0ktHTsJ+LE92EMfr3QifOf9JyvxASN8YiZzP9TQUhT5X63d Om5tUCALsd6/V7Q9ugHL0g==; Date: Fri, 07 Nov 2025 18:57:58 +0200 Message-Id: <86zf8x93vt.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87o6pd24qf.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 16:21:32 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> <878qgh3kxh.fsf@HIDDEN> <86346pakzl.fsf@HIDDEN> <87o6pd24qf.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (---) > Date: Fri, 07 Nov 2025 16:21:32 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> >> Whenever we're about to, we discover "input" that should be handled > >> >> first. > >> > > >> > Which input is that? > >> > >> "Keyboard" input (actually input on the X socket or equivalent), IIUC. > > > > But I didn't press any keys when running the test program. And I also > > Many FDs are registered as "keyboard" input: add_read_fd does that > (add_non_keyboard_read_fd is the function that doesn't). That might > also need fixing, but it's not the original bug, which is that any > "keyboard" input will cause a busy infloop and fail to run the sentinel. So let's please identify the "keyboard input" that is part of this particular scenario. Without that, I submit that we don't really understand the problem. > > ran it in a -nw session, where no input events should happen except > > via keyboard keys. So where does keyboard input come from? If this > > is the root cause of the loop, we must understand how it comes into > > play. > > What system is this on? On this one: $ uname -a Linux maintain0p.gnu.org 5.15.0-157-generic #167+11.0trisquel31 SMP Wed Oct 1 08:27:38 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux > On GNU/Linux, the inotify fd, the timer fd, and the > child_signal_read self-pipe are all registered as "keyboard" input. So which one prevents us from running the sentinel in this case? The inotify descriptor should be ready to read just once, timers should not fire every 0.1 sec, and self-pipe, if it's ready, should have told us that the process exited, and we should have run the sentinel then, right? > But, again, this is a different bug: even if only the actual keyboard FD > were marked as keyboard input, we'd still fail to run a sentinel here. If the keyboard descriptor is ready for reading, not running the sentinel is what's expected from Emacs: keyboard input gets preference. Anyway, maybe it's a different bug, but without a complete understanding of it, we are not prepared to discuss solutions, don't you agree?
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:51:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:51:37 2025 Received: from localhost ([127.0.0.1]:46947 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHPgX-000528-9t for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:51:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36668) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHPgT-00051y-Qs for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:51:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHPgM-00008o-L9; Fri, 07 Nov 2025 11:51:27 -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=YTx6FarYXBvtjgZ92nSZykI4Tai/0T9sADDmnvK6Nzo=; b=UaEbBHh+BIEH xM7wwW/5n2vKf6ItyNCm0Yr808OWd6lhfueRKckoSc2MP9ajapbEjlY2oVsgNOERKHI2Qz1aW7aEm /Hh7H6P4CklYhl+0RkLKcWlgi+WDh39TBNIRzDLzXFPjhvgqpMNiOO5Ixzmk+GPI25Oed6/BAYLvg jHzo7i114M3iEM03XPViB7d6BDRLAqeUSx5c8UIcj8Z1jb2aiLUNQKdRcoCko+/Re0dawt9jwhyb6 4X5wbwg9I1MEb8HgB0zxPSFI7aluNDYcY8QpTPwGnrfDEBb1I1TyAHAfZ+gxUKOsZp26Qrv/tbKN+ uXW89f3pkQs5ZUFlS1uk2A==; Date: Fri, 07 Nov 2025 18:51:23 +0200 Message-Id: <861pm9air8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87tsz525hd.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 16:05:25 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> <87tsz525hd.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (---) > Date: Fri, 07 Nov 2025 16:05:25 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, > >> Paul Eggert <eggert@HIDDEN> > >> Date: Fri, 07 Nov 2025 10:18:47 -0500 > >> From: Spencer Baugh via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > >> > >> >> That change looks harmless, but I think it indicates something else in > >> >> the code is incorrect. > >> > > >> > I think the whole approach of using two select calls is very fragile. > >> > >> Agreed, I think that's the root of the problem. I have previously found > >> other bugs related to this update_tick select call, so I do think it's > >> time to just get rid of it. > > > > It's a non-starter for me, so please don't propose changes that remove > > the first call to thread_select. > > Can you provide a reason for that? The first call clearly seems to be > unnecessary and harmful. I simply don't trust this conclusion. That call was there for decades, so we should have some minimal respect to those who wrote it and those who used it for all those years: they generally knew what they were doing. By contrast, we have been looking at this code for the whole of half a day. Really, a bit of modesty is called for.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:21:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:21:47 2025 Received: from localhost ([127.0.0.1]:46731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHPDf-0003Zk-E2 for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:21:47 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:14733) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHPDb-0003Ze-VU for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:21:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762532496; x=1762791696; bh=sSvNb9B3Ih+QLSNUMV7+RzZ/3YgCJOQetinj0a8PhDk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Y0OvkY72vte9FrRJxVIVaUHi1DHqBRBTz/5RhAV/Zk6sy6uZvFw6iwFIPAChTFDQ0 54Ky0IsHSZl8o0wDYMKYjLYvK0YRqW/XJKXl7TDin54B4QSsAiRBnDjPXPgH3lEd0e tCtWnJ40lc2qnC7kt0cXgREs+s8H571VglzNSF8/VMa5fCs77X6/3afgbVcZix/2kA 9L2csogINAAknzSsKgrZ4VvIMuF7dNb6eJp1BkHElIAdoGZ2aY57hC9TYrAmRMTRRP mviJuEEhXh7S8dG0gXmlT4icfzXhIqSQRPggEgYkG8q9AqDiJma8tJzkn0Vzjp2GEs CTJ+vAguY/rQw== Date: Fri, 07 Nov 2025 16:21:32 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87o6pd24qf.fsf@HIDDEN> In-Reply-To: <86346pakzl.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> <878qgh3kxh.fsf@HIDDEN> <86346pakzl.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 211766e62980b4f4f506dc88b00304f6816db6d4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 15:46:23 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN= om, dmitry@HIDDEN, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> Date: Fri, 07 Nov 2025 15:00:35 +0000 >> >> From: Pip Cet <pipcet@HIDDEN> >> >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@janestree= t.com, dmitry@HIDDEN, eggert@HIDDEN >> >> >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> >> >> We're failing to run status_notify even though process status has >> >> >> changed. >> >> > >> >> > Yes, that's clear. But why do we fail to run status_notify and/or = the >> >> > sentinel? >> >> >> >> Whenever we're about to, we discover "input" that should be handled >> >> first. >> > >> > Which input is that? >> >> "Keyboard" input (actually input on the X socket or equivalent), IIUC. > > But I didn't press any keys when running the test program. And I also Many FDs are registered as "keyboard" input: add_read_fd does that (add_non_keyboard_read_fd is the function that doesn't). That might also need fixing, but it's not the original bug, which is that any "keyboard" input will cause a busy infloop and fail to run the sentinel. > ran it in a -nw session, where no input events should happen except > via keyboard keys. So where does keyboard input come from? If this > is the root cause of the loop, we must understand how it comes into > play. What system is this on? On GNU/Linux, the inotify fd, the timer fd, and the child_signal_read self-pipe are all registered as "keyboard" input. But, again, this is a different bug: even if only the actual keyboard FD were marked as keyboard input, we'd still fail to run a sentinel here. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:05:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:05:41 2025 Received: from localhost ([127.0.0.1]:46620 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOy4-00009f-Rp for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:05:41 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:63837) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHOy2-00009X-G2 for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:05:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762531531; x=1762790731; bh=b0CxdY3y0rtheD4de54qywUd0pN93qrd5D5LKtLzOpw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=uZ1ibAmSVal6gqSkgVzu+0bgcJNZxTLcX912NFNwxC4YAxqK7nUJEY597PZ0txZMW q2wxlnFdNQFN+8XE6QUFBYD0D12jNcciscjEEWmTnBB9gNzsBxPzcokJpJXgpVA+Ac 5+XFy3EOeQmM75qoUOdPtp8g7j/297RLao002YqFpDPmIPd8fs04m4WJcd8GnrE+on ucksF/99Vy4zsX2vyaPQX+mnuu9oQHKpOnkrfrdERGBWrgeFC+yFu2UW3sNQOQOr5A 9XeStgqXoIYr3H+HpCq2l1zX5IcpkiinprGXqgTfHfm95nb8VgYviRql2oBRUKnZwH O3jRQ14hu0pkA== Date: Fri, 07 Nov 2025 16:05:25 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87tsz525hd.fsf@HIDDEN> In-Reply-To: <865xblalac.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> <865xblalac.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: e60813f36c098c64f5be3cae948a980e5df667bd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: Spencer Baugh <sbaugh@HIDDEN>, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, >> Paul Eggert <eggert@HIDDEN> >> Date: Fri, 07 Nov 2025 10:18:47 -0500 >> From: Spencer Baugh via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> >> That change looks harmless, but I think it indicates something else = in >> >> the code is incorrect. >> > >> > I think the whole approach of using two select calls is very fragile. >> >> Agreed, I think that's the root of the problem. I have previously found >> other bugs related to this update_tick select call, so I do think it's >> time to just get rid of it. > > It's a non-starter for me, so please don't propose changes that remove > the first call to thread_select. Can you provide a reason for that? The first call clearly seems to be unnecessary and harmful. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 16:03:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 11:03:23 2025 Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOvr-0008Tf-3H for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:03:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46646) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOvo-0008TV-Ko for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 11:03:21 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOvi-0003At-5n; Fri, 07 Nov 2025 11:03: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=Pur2vAiiTlVIWOKHR24T7c1MSZCFMxgf7wt+D7PzUZ4=; b=OB5xeuW0P5+U GSJjFov6qRhNkfk/MLTRW7c+eNwIw6QNfe6jmxQgoNvrtrSWFEKgo7DD9Rd37gvH9zYuMgav/Uv3z DAfAuRviTmFLTUlS49uuYL6VGkM64vzjN0QVghZ9vgyG3oyi5m3B7MFvOww2JuUrVDWhn3ZYP7+Pp sNxsCzR1SOQtTcFzKipnfBNr2y6+c5dhGzlXV5MgXgj+Ku8jq5w58GdcXNJDV56bKKXtlZJOwVcNw 1P0m+Ne9w2EEjB+mz79tNzVzP90dBxtW9m/DK8AJ5tOnPim7cxpZwAhUNdR7QubDNC2slRbuY8S0T /2NBstUfPoIqtHYpZkR6eg==; Date: Fri, 07 Nov 2025 18:03:10 +0200 Message-Id: <86346pakzl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <878qgh3kxh.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 15:46:23 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> <878qgh3kxh.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (---) > Date: Fri, 07 Nov 2025 15:46:23 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> Date: Fri, 07 Nov 2025 15:00:35 +0000 > >> From: Pip Cet <pipcet@HIDDEN> > >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > >> > >> "Eli Zaretskii" <eliz@HIDDEN> writes: > >> > >> >> We're failing to run status_notify even though process status has > >> >> changed. > >> > > >> > Yes, that's clear. But why do we fail to run status_notify and/or the > >> > sentinel? > >> > >> Whenever we're about to, we discover "input" that should be handled > >> first. > > > > Which input is that? > > "Keyboard" input (actually input on the X socket or equivalent), IIUC. But I didn't press any keys when running the test program. And I also ran it in a -nw session, where no input events should happen except via keyboard keys. So where does keyboard input come from? If this is the root cause of the loop, we must understand how it comes into play.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:56:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:56:53 2025 Received: from localhost ([127.0.0.1]:46556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOpY-0005Sz-Sn for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:56:53 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57270) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOpX-0005St-3v for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:56:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOpR-0006pQ-Eu; Fri, 07 Nov 2025 10:56:45 -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=CZ0HIOem/IImav86VLmND4/+HaBnkY/NxrlUGIV43rI=; b=Gs9CFIiAMDer 9u2y86havVganb0y92aBmaybyo6He7NamCd5Hif3rJ+wUVk5TTWjyqPT03WiDqz+nukCBH1XK9km0 rQQc+c4qvzWqJI3Ac0zH/2+RyKzOWQSU7l5mSACyqeqmzNCesMW2lhurrazPsCwUkoUgp1D/0YK47 H5VC0Oe6CPYqUHdoKtMP/CiKlg3dtirZUxVk3STL13TjJNxNHqO94EWr0u96rsHahd2cvn5ZysAC5 XHkuKaFTFdfsSyxrD2b4UwTErpGsK6axdGYR8WLWspl/rQ/tzqWQVNBihJ1hKTs5WRYAHEPzieorG FqRTe0WH4FtH+h3JL+4ZkA==; Date: Fri, 07 Nov 2025 17:56:43 +0200 Message-Id: <865xblalac.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier346p7two.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN> <87pl9u2bex.fsf@HIDDEN> <ier346p7two.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, pipcet@HIDDEN, eggert@HIDDEN, 79777 <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 (---) > Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org, > Paul Eggert <eggert@HIDDEN> > Date: Fri, 07 Nov 2025 10:18:47 -0500 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > >> That change looks harmless, but I think it indicates something else in > >> the code is incorrect. > > > > I think the whole approach of using two select calls is very fragile. > > Agreed, I think that's the root of the problem. I have previously found > other bugs related to this update_tick select call, so I do think it's > time to just get rid of it. It's a non-starter for me, so please don't propose changes that remove the first call to thread_select.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:46:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:46:45 2025 Received: from localhost ([127.0.0.1]:46454 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOfg-00055o-LQ for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:46:44 -0500 Received: from mail-24416.protonmail.ch ([109.224.244.16]:49599) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHOfc-00055b-CC for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:46:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762530389; x=1762789589; bh=zLQNwES8IOVBrEMWLKnic4YohHPCpzvboYMtQIVAQ/c=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=hucfcTVpLeJClTAWWcuXerZx6O//A3Nqf9c71gJy5lCFqQBrQa7bSu1Q3xLkOfSdO VrTIFU+zjQXYb+s4uYu9rGhETOyiho51zjETp/P8YwYJ7akm2s5v0bxgus3V6UAaUS 8/iFSVtuU1rzS5+aehPQoBB9TrqYEUiyp9afugS8JdjDMwR7ClIXHUYIhoxR9hA7/f drheCtU8kmtFuthKQWE+DfcY6ifzVEhN2g5bCurB4Pd/d/FzRuyDpfQSIKn89kLQ9I i9Xqnzi9KEhGx/YL5+qX/28kwssCu7sOzNRm57Q7f1pD0GjTv6fjrjiJXa8zbdAmCA j+JpB1gpm/jdw== Date: Fri, 07 Nov 2025 15:46:23 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <878qgh3kxh.fsf@HIDDEN> In-Reply-To: <868qghamxf.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> <868qghamxf.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9216e7756573b52eb2a5799bd1b4a6ea87ca2a65 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 15:00:35 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN= om, dmitry@HIDDEN, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> We're failing to run status_notify even though process status has >> >> changed. >> > >> > Yes, that's clear. But why do we fail to run status_notify and/or the >> > sentinel? >> >> Whenever we're about to, we discover "input" that should be handled >> first. > > Which input is that? "Keyboard" input (actually input on the X socket or equivalent), IIUC. >> > That is already a better candidate for the fix, because it >> > special-cases the read_kbd case, but read_kbd is not a boolean, it's a >> > tristate. >> >> Indeed, and this code does the right thing for all values, just like in >> all other locations that set the FD mask. > > Please tell more: how does it does TRT for both of the non-zero > values? if read_kbd is 0 (as it is in Spencer's test case), we ignore keyboard input, so we shouldn't add the keyboard fd(s) to our fd mask. if read_kbd is 1, we're not ignoring keyboard input, so we should add them: we'll read keyboard input as ordinary input and exit the loop. if read_kbd is -1, we're not ignoring keyboard input, so we should add them (but we exit in a different way) This is the same as the existing caller under the "Wait till there is something to do" comment. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:22:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:22:19 2025 Received: from localhost ([127.0.0.1]:46273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOI3-0003uW-5Q for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:22:19 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33001) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vHOI0-0003uB-So for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:22:14 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever In-Reply-To: <87ecq93n1t.fsf@HIDDEN> (Pip Cet's message of "Fri, 07 Nov 2025 15:00:35 +0000") References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> Date: Fri, 07 Nov 2025 10:22:07 -0500 Message-ID: <ierzf8x6f6o.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1762528927; bh=idVWbueYHkZZNvdNl9KhaykhZD4K8aqWNCpOT4evbKo=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=ss4oobXPPFFAGHx2aFoLDeaW8S0G+ukrtd6j695xze4pVgMUgu3jHj7+CybKoeaQ6 m0sqqXnG6llq4OKzrBTU6R/2hI4p0KzpJksKw9nDxyStiU7QtGFn1SB7h0ImW3liRw zKDFM0hVh2A0CLJML5ZdKvXP6aqq4BUyhHiRTAO5Vnr66NpUhQp35e+YqUlxcENsst qVSpXbhXrtnnfUAvVA0yfDlEcrSYjGcAd8rUQ4GQ+sSmJ/4JkCNeXaYfuYh/c/Tw2b nhK7XgT3cOmTEkW+S2S72loZItA+CO2pvrCwS3DyqZnDFFsjN5ZccOgSXafYaqroUB qTQ1Dc7u/hLtw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, eggert@HIDDEN, 79777 <at> debbugs.gnu.org, monnier@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 (---) Pip Cet <pipcet@HIDDEN> writes: > "Eli Zaretskii" <eliz@HIDDEN> writes: > >>> Date: Fri, 07 Nov 2025 13:06:39 +0000 >>> From: Pip Cet <pipcet@HIDDEN> >>> Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN >>> >>> "Eli Zaretskii" <eliz@HIDDEN> writes: >>> >>> > (The original patch also removed the call to thread_select, which >>> > makes even less sense.) >>> >>> Makes sense to me, I must say: if process_tick changed, we should run >>> status_notify, whether or not there is other input. The rest is >>> cosmetics (whether to redisplay, for example). >> >> First, thread_select allows another thread to take the global lock, so >> removing that call will potentially harm responsiveness of other >> threads. > > Calling it twice in rapid succession rather than just once should not > affect responsiveness. Agreed, it won't harm responsiveness since the second select call (in your patch) happens immediately after anyway. >> And second, I think you forget about keyboard input: if it's >> available, we don't want to process output from sub-processes, at >> least not in some calling scenarios. > > See the other emails. We probably want to give ordinary input priority > over sentinels, but that can be achieved without duplicating the select > call. Or we can keep the call and ignore its return value. > >>> > I actually don't think I understand the root cause(s) of the original >>> > bug. What exactly causes wait_reading_process_output loop >>> >>> We're failing to run status_notify even though process status has >>> changed. >> >> Yes, that's clear. But why do we fail to run status_notify and/or the >> sentinel? > > Whenever we're about to, we discover "input" that should be handled > first. Then we fail to handle that input, because it's on an FD we're > not actually interested in. So we infloop. This is my understanding too. >>> > I think what we see happens because sleep-for is meant to sleep >>> > unconditionally, and the process sentinel is only run when Emacs is >>> > idle (and not sleeping in sleep-for). Thus, the while loop at the end > > What you said here amounts to "sleep-for does not run sentinels". > > That contradicts both the code, which runs process sentinels in > sleep-for, and the documentation, which clearly states not only that it > does, but that it is the recommended way of doing so. > > sleep-for runs sentinels. Please also remember that sleep-for isn't necessary to trigger the bug. It happens also if you replace (sleep-for 1) with (accept-process-output nil 1). So I think we don't need to talk about sleep-for.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:21:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:21:29 2025 Received: from localhost ([127.0.0.1]:46265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHOHI-0003tR-J1 for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:21:28 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54096) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHOHF-0003tL-Tn for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:21:27 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHOH9-0006RZ-Gc; Fri, 07 Nov 2025 10:21:19 -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=WRwuefKZe/gD4l9h9ERJIM1cmnOe2NFv05eG76PScgg=; b=d4TleyZdEds1 kCqi0rGxLmzU5V2fn/gPYygLtljk2QnnLp7VgRT8ecEJav43OzsBkSLhPZ2k7gGTYQYIdkMSPQMV5 fjw3+CUdk4x8R+VTXJogemkyfsL26ktYK4d0RUD0PMDbBmP+A0N6czLB2CeGImTgSEV9uNMO3LKLi yjM2sr2z7/uQYZxHBfi78yWjuJIDbZg5nQagZZOQc6A8UpvF94QThZ8VdOnJrlMpmCT/U9gMopo/w SV3ck0kPSP+7CzU5nghEb5ann22nKyfphsZVF5iKIkDoT42i5mGsfYvseyxDivPo8EGDWsPX6PYtF FatbKOviDt0iR3E7yoLbng==; Date: Fri, 07 Nov 2025 17:21:16 +0200 Message-Id: <868qghamxf.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ecq93n1t.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 15:00:35 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> <87ecq93n1t.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (---) > Date: Fri, 07 Nov 2025 15:00:35 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: monnier@HIDDEN, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> We're failing to run status_notify even though process status has > >> changed. > > > > Yes, that's clear. But why do we fail to run status_notify and/or the > > sentinel? > > Whenever we're about to, we discover "input" that should be handled > first. Which input is that? > > That is already a better candidate for the fix, because it > > special-cases the read_kbd case, but read_kbd is not a boolean, it's a > > tristate. > > Indeed, and this code does the right thing for all values, just like in > all other locations that set the FD mask. Please tell more: how does it does TRT for both of the non-zero values?
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:18:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:18:58 2025
Received: from localhost ([127.0.0.1]:46231 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHOEr-0003jv-RZ
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:18:58 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:41601)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHOEn-0003jl-Lg
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:18:56 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
In-Reply-To: <87pl9u2bex.fsf@HIDDEN> (Pip Cet's message of "Fri, 07
Nov 2025 13:57:18 +0000")
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
<87pl9u2bex.fsf@HIDDEN>
Date: Fri, 07 Nov 2025 10:18:47 -0500
Message-ID: <ier346p7two.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762528727;
bh=8soTaeqNH9FsPsjY5RL/ZwA4V9s1lY70TMEaf9CXMqw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=g7S2anEOxZi3mZU8WmCnLQ2EwKqi0/r6VNviSidmvb54y2+CbeErPX1kmYjLoiSL5
toc5oDcPoS/avvSKEpcOFDuLi8MWf19bhMxV0e4w1CSOfPkPbZe7Y/I1tmsexN/Cvu
ukhffYVKwmH0MxSoLOcA9dm/pdC8siAjUBSkbf9u1aMpQ87zVGRoFfd44YF9y3xS8G
jAcE2NnZREIWHKk2KCgr98F34bBoG3MEKZnJQ6Yj4XR3eP9QiUM2yd/QQGteizK85w
xJ6OxUXW3J5XuIkFb0NsjWBtehy7gLRc4DURR7kTNHXOc/QpgojXuKqG7ko20sAND/
wNfDm3ISGOFjw==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@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 (---)
Pip Cet <pipcet@HIDDEN> writes:
> "Spencer Baugh" <sbaugh@HIDDEN> writes:
>
>> On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wro=
te:
>>
>> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of=
text editors\""
>> <bug-gnu-emacs@HIDDEN> writes:
>>
>> > The following patch fixes it, cleaning up an area of troublesome code
>> > which has caused a number of recent bugs.
>>
>> > [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick=
.patch]...
>>
>> IIUC, this is equivalent to changing a single condition here:
>>
>> diff --git a/src/process.c b/src/process.c
>> index 33d96198573..7368e242c7d 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,=
int nsecs,
>> int read_kbd,
>> &Atemp,
>> (num_pending_connects > 0 ? &Ctemp : NULL=
),
>> NULL, &timeout, NULL)
>> - <=3D 0))
>> + <=3D 0)
>> + || true)
>> {
>> /* It's okay for us to do this and then continue with
>> the loop, since timeout has already been zeroed out. =
*/
>>
>> (your patch the simplified the remaining code, but maybe it's easier to
>> understand if we go through the logical change first).
>>
>> Yes.
>
> Okay, thanks for helping me understand. My impression is we shouldn't do
> that: if input is available, and we also want to run a sentinel, it's
> better to handle the input first, then run the sentinel only when no
> further input is available. That way, even if the sentinel somehow
> causes another sentinel (or itself) to run, Emacs will stay usable.
Hm, that's fair.
>> That change looks harmless, but I think it indicates something else in
>> the code is incorrect.
>
> I think the whole approach of using two select calls is very fragile.
Agreed, I think that's the root of the problem. I have previously found
other bugs related to this update_tick select call, so I do think it's
time to just get rid of it.
> How about we just zap the timeout, so we know the next select call will
> return immediately; and then run the sentinels only if nfds =3D=3D 0 (so =
no
> further input was received)?
>
> This keeps the current priority logic, but ensures the sentinel messages
> will still be visible.
Ah, great idea! Yes, that seems like a good approach.
>> > Previously in wait_reading_process_output, if we saw that
>> > update_tick !=3D process_tick, we only called status_notify if it
>> > wasn't also some other kind of input which would cause
>> > status_notify to be called.
>>
>> I'm not sure I understand this sentence. My impression is that we called
>> status_notify in the code above if there was no input available on any
>> of the FDs compute_input_wait_mask returned, but the other select used a
>> different FD set.
>>
>> Sure sure, this sentence is describing the intention. It mostly works b=
ut didn't quite always work due to the mask difference.=20
>
> I still don't understand the sentence in your commit message, sorry.
Eh, don't worry about it, it doesn't add anything to the discussion.
>> > When these select masks are different, the "if (update_tick !=3D
>> > process_tick)" branch can detect input (in this case from file-notify)
>> > which the main select will not see, causing the busy-looping behavior.
>>
>> Why are the select masks different, though? Wouldn't it suffice to make
>> them the same, like this?
>
>> The mask can be computed in many other different ways too, if you look a=
t the code.
>
> Thanks. I wouldn't say "many", but there are a few cases, all of which
> would have to be looked at; unless we decide to avoid the second select
> call entirely and move some code, as discussed above.
Yes.
>> So this leaves a bunch of other potential bugs latent in the code.
>
> Quite possibly, but it seems to me this specific bug can be fixed on its
> own, and then we can discuss further patches as they become relevant.
>
> In summary, your patch does two things:
>
> 1. fix the infloop
> 2. give sentinels priority over ordinary input
>
> We want (1), but not (2), so can we look for a patch that does that?
Right.
> Here's my idea for how to do it, merely for demonstration at this point:
>
> diff --git a/src/process.c b/src/process.c
> index 86e83e58c56..3ba70235678 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5519,44 +5519,10 @@ wait_reading_process_output (intmax_t time_limit,=
int nsecs, int read_kbd,
> if (read_kbd < 0 && kbd_is_ours ())
> set_waiting_for_input (&timeout);
>=20=20
> - /* If status of something has changed, and no input is
> - available, notify the user of the change right away. After
> - this explicit check, we'll let the SIGCHLD handler zap
> - timeout to get our attention. */
> + /* If a process status has changed, we want to react as soon as
> + all available input has been handled. */
> if (update_tick !=3D process_tick)
> - {
> - fd_set Atemp;
> - fd_set Ctemp;
> -
> - if (kbd_on_hold_p ())
> - FD_ZERO (&Atemp);
> - else
> - compute_input_wait_mask (&Atemp);
> - compute_write_mask (&Ctemp);
> -
> - /* If a process status has changed, the child signal pipe
> - will likely be readable. We want to ignore it for now,
> - because otherwise we wouldn't run into a timeout
> - below. */
> - int fd =3D child_signal_read_fd;
> - eassert (fd < FD_SETSIZE);
> - if (0 <=3D fd)
> - FD_CLR (fd, &Atemp);
> -
> - timeout =3D make_timespec (0, 0);
> - if ((thread_select (pselect, max_desc + 1,
> - &Atemp,
> - (num_pending_connects > 0 ? &Ctemp : NULL),
> - NULL, &timeout, NULL)
> - <=3D 0))
> - {
> - /* It's okay for us to do this and then continue with
> - the loop, since timeout has already been zeroed out. */
> - clear_waiting_for_input ();
> - got_some_output =3D status_notify (NULL, wait_proc);
> - if (do_display) redisplay_preserve_echo_area (13);
> - }
> - }
> + timeout =3D make_timespec (0, 0);
>=20=20
> /* Don't wait for output from a non-running process. Just
> read whatever data has already been received. */
> @@ -5844,6 +5810,15 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs, int read_kbd,
>=20=20
> if (nfds =3D=3D 0)
> {
> + /* There was no input, but the status of a process has
> + changed. Run the sentinel, and redisplay so the user can
> + see the sentinel message. */
> + if (update_tick !=3D process_tick)
> + {
> + got_some_output =3D status_notify (NULL, wait_proc);
> + if (do_display) redisplay_preserve_echo_area (13);
> + }
> +
> /* Exit the main loop if we've passed the requested timeout,
> or have read some bytes from our wait_proc (either directly
> in this call or indirectly through timers / process filters=
),
>
> Do you have other ideas? (Note that the clear_waiting_on_input call also
> becomes unnecessary in this patch).
I think this is a very elegant solution, I like it.
It nicely preserves the existing behavior of prioritizing input over
sentinels, while fixing the buggy implementation with two select calls.
I prefer this patch over the one I posted. If it passes make check and
my repro, I'm in favor of installing it.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 15:00:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 10:00:52 2025 Received: from localhost ([127.0.0.1]:46114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHNxL-0003BR-GZ for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:00:52 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:56365) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1vHNxH-0003BJ-38 for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 10:00:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1762527640; x=1762786840; bh=rrr33KsIkzkhW0uLT7UrP4XmRAmBgwBtPDkrwTpFPWA=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XgcMEpNcEWucwFjoXGcW04tWy2x9s7tmjmUvlJEL1mbHvQ3AhucBkSE0NPxevhJK3 lr2ZYUrQWbkhs/+rUsHMav+Qjq3Chn/8d4YnKzfCDd1TTjFCx9zJfFwp+wV0M/j1y4 xoLhT6TeyhMnJChTOTyd4WfEZNI6vIcvFq1en0E2r0hMuHNortUtw3PIWPK334oXVf 76w8Pj0xK0Brj3CHrsxHDFVGFKEVtYy/qJ1fBFWudwkFB2FM+GEvlTHNEpvXTiYFGT SXENfHHTQtPcPP70c9zivaFfwn6kiYc02HtYdpO2J0Qc1ZaBRul4Pec48WvscdQmUL 7rSVUMhBq2JTw== Date: Fri, 07 Nov 2025 15:00:35 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever Message-ID: <87ecq93n1t.fsf@HIDDEN> In-Reply-To: <86h5v69bbe.fsf@HIDDEN> References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> <86h5v69bbe.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a09a58b2b8335a0a32696927cdcb3a92de9f69dd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Fri, 07 Nov 2025 13:06:39 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sb= augh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN >> >> "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> > (The original patch also removed the call to thread_select, which >> > makes even less sense.) >> >> Makes sense to me, I must say: if process_tick changed, we should run >> status_notify, whether or not there is other input. The rest is >> cosmetics (whether to redisplay, for example). > > First, thread_select allows another thread to take the global lock, so > removing that call will potentially harm responsiveness of other > threads. Calling it twice in rapid succession rather than just once should not affect responsiveness. > And second, I think you forget about keyboard input: if it's > available, we don't want to process output from sub-processes, at > least not in some calling scenarios. See the other emails. We probably want to give ordinary input priority over sentinels, but that can be achieved without duplicating the select call. Or we can keep the call and ignore its return value. >> > I actually don't think I understand the root cause(s) of the original >> > bug. What exactly causes wait_reading_process_output loop >> >> We're failing to run status_notify even though process status has >> changed. > > Yes, that's clear. But why do we fail to run status_notify and/or the > sentinel? Whenever we're about to, we discover "input" that should be handled first. Then we fail to handle that input, because it's on an FD we're not actually interested in. So we infloop. >> > I think what we see happens because sleep-for is meant to sleep >> > unconditionally, and the process sentinel is only run when Emacs is >> > idle (and not sleeping in sleep-for). Thus, the while loop at the end What you said here amounts to "sleep-for does not run sentinels". That contradicts both the code, which runs process sentinels in sleep-for, and the documentation, which clearly states not only that it does, but that it is the recommended way of doing so. sleep-for runs sentinels. >> The problem is that "the next select" doesn't look at the keyboard fd, >> but our "check" select does, so what ends up happening is that we skip >> the process status change (thinking the next select will do it), but the >> next select doesn't exit the loop, because it ignores the keyboard fd. > > What is "the next select"? which of the two calls to thread_select do There are two calls, so when I say "the next select", I mean the second one. > you allude to here, and why do you say that we need to look at > keyboard input? We don't. The bug is that the first select looks at keyboard input, not that the second select fails to. >> Just for completeness, there was a thinko in my last patch: >> >> diff --git a/src/process.c b/src/process.c >> index 86e83e58c56..099e205344b 100644 >> --- a/src/process.c >> +++ b/src/process.c >> @@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, = int nsecs, int read_kbd, >> >> if (kbd_on_hold_p ()) >> FD_ZERO (&Atemp); >> - else >> + else if (! read_kbd) >> +=09 compute_non_keyboard_wait_mask (&Atemp); >> +=09 else >> compute_input_wait_mask (&Atemp); >> =09 compute_write_mask (&Ctemp); >> >> >> would have been the correct patch, sorry about that. > > That is already a better candidate for the fix, because it > special-cases the read_kbd case, but read_kbd is not a boolean, it's a > tristate. Indeed, and this code does the right thing for all values, just like in all other locations that set the FD mask. Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 14:17:38 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 09:17:38 2025 Received: from localhost ([127.0.0.1]:45921 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHNHV-00017o-9g for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 09:17:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57060) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHNHS-00017g-9W for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 09:17:35 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHNHL-0000L2-Iv; Fri, 07 Nov 2025 09:17:27 -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=5A10va8ApnDbAV+FO6sei+hpXc4qE83mZL4wXIea1Uo=; b=HhdHKlAPDK7G bbvOQ9orlfhH/OWNnyA0iOtllkilPBB34MX1mqLNQNcjUQ3GHDFN3dIG4fVRhOJKHj4f+xZBvag31 daSTvul3mKuMQl0kRy7XKGNxZfCWXmfqq6X9LYfmie4GGjSU8au49LwnITfgbjvlBSaKnr/5au+OM 5GGGxo2eBwHdlj873VZeiXnNfoYPmBQ06+CGurMVD45CXuCj1bAusSHywfP/SNXEjZVmccr4d9Xn6 HAQ0/S2pDsJm0pnXyX5HK3wDyzjKxcboIWrAHFu5Ta7cYbqWbMOCn6jim38eRetEP61n3k4oY+2H+ WhYVnpopErAJvaO7nOvjuQ==; Date: Fri, 07 Nov 2025 16:17:25 +0200 Message-Id: <86h5v69bbe.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87v7jm2drb.fsf@HIDDEN> (message from Pip Cet on Fri, 07 Nov 2025 13:06:39 +0000) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN> <86ldki9hla.fsf@HIDDEN> <87v7jm2drb.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN, monnier@HIDDEN, dmitry@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 (---) > Date: Fri, 07 Nov 2025 13:06:39 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Stefan Monnier <monnier@HIDDEN>, 79777 <at> debbugs.gnu.org, sbaugh@HIDDEN, dmitry@HIDDEN, eggert@HIDDEN > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > (The original patch also removed the call to thread_select, which > > makes even less sense.) > > Makes sense to me, I must say: if process_tick changed, we should run > status_notify, whether or not there is other input. The rest is > cosmetics (whether to redisplay, for example). First, thread_select allows another thread to take the global lock, so removing that call will potentially harm responsiveness of other threads. And second, I think you forget about keyboard input: if it's available, we don't want to process output from sub-processes, at least not in some calling scenarios. > > I actually don't think I understand the root cause(s) of the original > > bug. What exactly causes wait_reading_process_output loop > > We're failing to run status_notify even though process status has > changed. Yes, that's clear. But why do we fail to run status_notify and/or the sentinel? > > indefinitely because there's a single (AFAIU) file notification? > > Also, on MS-Windows the file notifications don't work via > > pselect-testing of file descriptors, but the test case hangs anyway. > > Interesting. Do any of the patches help? I didn't try them, because they won't teach me anything at this stage. But see my other mail with description of some experiments I did with small variations of the original script. We need to explain all of those behaviors before we discuss patches, IMO. > > I think what we see happens because sleep-for is meant to sleep > > unconditionally, and the process sentinel is only run when Emacs is > > idle (and not sleeping in sleep-for). Thus, the while loop at the end > > That's incorrect. status_notify calls exec_sentinel, which runs the > sentinel even though Emacs is sleeping in sleep-for. I meant we don't call status_notify because Emacs is not idle. > > of the test program prevents Emacs from running the sentinel. In > > which case what we see is the expected and documented behavior, not a > > bug at all. > > The documentation says: > > A sentinel runs only while Emacs is waiting (e.g., for terminal > input, or for time to elapse, or for process output). This avoids the > > I think sleep-for counts as "Emacs is waiting for time to elapse". I'm not sure, that's the whole point of what I'm saying above. sleep-for does not wait for input, it waits for the time to pass. > The manual goes on to recommend that sleep-for be used to ensure > sentinels can run. So maybe the manual is wrong. Or please explain what happens here, and how the file notifications are involved. (I think the file notifications are largely a red herring: they just keep Emacs busy for enough time to trigger the behavior. IOW, the issue here is fine timing of the process demise vs the loop with sleep-for.) > > So I think there's more to this than meets the eye, and we should > > understand the problem (such that it is) better before we discuss the > > solutions (if they are needed). > > I agree. What I think I understand so far is: > > The old logic was this: > > 1. a process status has changed > 2. we check whether the next select will definitely return right away > because input is available > 3. if so, wo don't handle the process status change, because we're about > to exit the loop anyway You begin the description too late. It should begin with make-process, because, on the one hand, it takes Emacs to get to the wait loop, and OTOH it takes time for the process to die. So the description should start earlier. In particular, we might have already checked the child pipe and have seen that it's ready to be read. And the inotify descriptor is perhaps also a factor. > The problem is that "the next select" doesn't look at the keyboard fd, > but our "check" select does, so what ends up happening is that we skip > the process status change (thinking the next select will do it), but the > next select doesn't exit the loop, because it ignores the keyboard fd. What is "the next select"? which of the two calls to thread_select do you allude to here, and why do you say that we need to look at keyboard input? and what input is available in 2 above? > Just for completeness, there was a thinko in my last patch: > > diff --git a/src/process.c b/src/process.c > index 86e83e58c56..099e205344b 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, > > if (kbd_on_hold_p ()) > FD_ZERO (&Atemp); > - else > + else if (! read_kbd) > + compute_non_keyboard_wait_mask (&Atemp); > + else > compute_input_wait_mask (&Atemp); > compute_write_mask (&Ctemp); > > > would have been the correct patch, sorry about that. That is already a better candidate for the fix, because it special-cases the read_kbd case, but read_kbd is not a boolean, it's a tristate.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:57:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:57:34 2025
Received: from localhost ([127.0.0.1]:45864 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMy5-0000Pm-Gx
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:57:34 -0500
Received: from mail-4316.protonmail.ch ([185.70.43.16]:18435)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHMy2-0000Pe-0x
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:57:31 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762523843; x=1762783043;
bh=4ETviTFQQcEpst3QtqgMuR4R+Xq0RGUKzbtXUhAgP28=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=JWTy+LzswIvDKWFwwhUpKjjExwHQfZTCmetDHU2E6ETlHetTfYpqx2J3pjpej9uty
mELjnLjfAA7r6EWCKc1GcQgpVMCiAB5eyo87EVxlsYUjL9Mu/9Ko+A1T/W4C0qahZC
eOtBtUTvxsdr3SUejSVbBbDCYHdv+iVEzG1BQznXhEXOFfsOHdnUcPo6w2gWs0FZIN
4yspdlb5pCvXOUh+fFtnZgaerTmJvxpPVf9a9cxc7/qQ3K5XnwMh2zj3xWUsZ3MNy6
0wxgNKyQGjT/ia/gU2G0zb29hxmlDUe5zT/VLrA+K23r6DtlEKy/riP1lScXT4+FJj
Uv1Ow6X3UfAQA==
Date: Fri, 07 Nov 2025 13:57:18 +0000
To: Spencer Baugh <sbaugh@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87pl9u2bex.fsf@HIDDEN>
In-Reply-To: <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: b42a55185facd2001962798b6e83fc18b78e7676
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@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 (-)
"Spencer Baugh" <sbaugh@HIDDEN> writes:
> On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wrot=
e:
>
> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of =
text editors\""
> <bug-gnu-emacs@HIDDEN> writes:
>
> > The following patch fixes it, cleaning up an area of troublesome code
> > which has caused a number of recent bugs.
>
> > [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.=
patch]...
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs,
> int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL)=
,
> NULL, &timeout, NULL)
> - <=3D 0))
> + <=3D 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. *=
/
>
> (your patch the simplified the remaining code, but maybe it's easier to
> understand if we go through the logical change first).
>
> Yes.
Okay, thanks for helping me understand. My impression is we shouldn't do
that: if input is available, and we also want to run a sentinel, it's
better to handle the input first, then run the sentinel only when no
further input is available. That way, even if the sentinel somehow
causes another sentinel (or itself) to run, Emacs will stay usable.
> That change looks harmless, but I think it indicates something else in
> the code is incorrect.
I think the whole approach of using two select calls is very fragile.
How about we just zap the timeout, so we know the next select call will
return immediately; and then run the sentinels only if nfds =3D=3D 0 (so no
further input was received)?
This keeps the current priority logic, but ensures the sentinel messages
will still be visible.
> > Previously in wait_reading_process_output, if we saw that
> > update_tick !=3D process_tick, we only called status_notify if it
> > wasn't also some other kind of input which would cause
> > status_notify to be called.
>
> I'm not sure I understand this sentence. My impression is that we called
> status_notify in the code above if there was no input available on any
> of the FDs compute_input_wait_mask returned, but the other select used a
> different FD set.
>
> Sure sure, this sentence is describing the intention. It mostly works bu=
t didn't quite always work due to the mask difference.=20
I still don't understand the sentence in your commit message, sorry.
> > When these select masks are different, the "if (update_tick !=3D
> > process_tick)" branch can detect input (in this case from file-notify)
> > which the main select will not see, causing the busy-looping behavior.
>
> Why are the select masks different, though? Wouldn't it suffice to make
> them the same, like this?
> The mask can be computed in many other different ways too, if you look at=
the code.
Thanks. I wouldn't say "many", but there are a few cases, all of which
would have to be looked at; unless we decide to avoid the second select
call entirely and move some code, as discussed above.
> So this leaves a bunch of other potential bugs latent in the code.
Quite possibly, but it seems to me this specific bug can be fixed on its
own, and then we can discuss further patches as they become relevant.
In summary, your patch does two things:
1. fix the infloop
2. give sentinels priority over ordinary input
We want (1), but not (2), so can we look for a patch that does that?
Here's my idea for how to do it, merely for demonstration at this point:
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..3ba70235678 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5519,44 +5519,10 @@ wait_reading_process_output (intmax_t time_limit, i=
nt nsecs, int read_kbd,
if (read_kbd < 0 && kbd_is_ours ())
=09set_waiting_for_input (&timeout);
=20
- /* If status of something has changed, and no input is
-=09 available, notify the user of the change right away. After
-=09 this explicit check, we'll let the SIGCHLD handler zap
-=09 timeout to get our attention. */
+ /* If a process status has changed, we want to react as soon as
+=09 all available input has been handled. */
if (update_tick !=3D process_tick)
-=09{
-=09 fd_set Atemp;
-=09 fd_set Ctemp;
-
- if (kbd_on_hold_p ())
- FD_ZERO (&Atemp);
- else
- compute_input_wait_mask (&Atemp);
-=09 compute_write_mask (&Ctemp);
-
-=09 /* If a process status has changed, the child signal pipe
-=09 will likely be readable. We want to ignore it for now,
-=09 because otherwise we wouldn't run into a timeout
-=09 below. */
-=09 int fd =3D child_signal_read_fd;
-=09 eassert (fd < FD_SETSIZE);
-=09 if (0 <=3D fd)
-=09 FD_CLR (fd, &Atemp);
-
-=09 timeout =3D make_timespec (0, 0);
-=09 if ((thread_select (pselect, max_desc + 1,
-=09=09=09 &Atemp,
-=09=09=09 (num_pending_connects > 0 ? &Ctemp : NULL),
-=09=09=09 NULL, &timeout, NULL)
-=09 <=3D 0))
-=09 {
-=09 /* It's okay for us to do this and then continue with
-=09=09 the loop, since timeout has already been zeroed out. */
-=09 clear_waiting_for_input ();
-=09 got_some_output =3D status_notify (NULL, wait_proc);
-=09 if (do_display) redisplay_preserve_echo_area (13);
-=09 }
-=09}
+=09timeout =3D make_timespec (0, 0);
=20
/* Don't wait for output from a non-running process. Just
=09 read whatever data has already been received. */
@@ -5844,6 +5810,15 @@ wait_reading_process_output (intmax_t time_limit, in=
t nsecs, int read_kbd,
=20
if (nfds =3D=3D 0)
=09{
+=09 /* There was no input, but the status of a process has
+=09 changed. Run the sentinel, and redisplay so the user can
+=09 see the sentinel message. */
+=09 if (update_tick !=3D process_tick)
+=09 {
+=09 got_some_output =3D status_notify (NULL, wait_proc);
+=09 if (do_display) redisplay_preserve_echo_area (13);
+=09 }
+
/* Exit the main loop if we've passed the requested timeout,
or have read some bytes from our wait_proc (either directly
in this call or indirectly through timers / process filters),
Do you have other ideas? (Note that the clear_waiting_on_input call also
becomes unnecessary in this patch).
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:52:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:52:41 2025
Received: from localhost ([127.0.0.1]:45853 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMtN-0000Fp-89
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:52:41 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:49670)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHMtI-0000Fh-TY
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:52:39 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHMtB-0005CJ-FN; Fri, 07 Nov 2025 08:52:29 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
Date; bh=UI7bPy7thaxZSaoZoixDKw4IhihDeUkVrXUcc9d5GSE=; b=lVAvXISTw1A7WX7kDfBo
OgPKJacZOUsNTRchOsctPIjI5Wv472pcASHh68j+xDQM5DJIrNhxzPzwaUk0dAY6giBfEzcHsFUfi
gZVI7hgADMwRLZYKoXdL55sQrcq29gp8YYiWdLns0aUX/Jq/bJuSPjA0pUAo365mG64V/sIpmk1Hm
VvF/EoLJcCwWba24H0y0I8tkK9/DX2KpkrRVhcR3qkmoCUe+BTkNYxxdU/FjMt2+g0WOks5fBmao2
lBPfScjr0lH7+FYqZXuaG14hjRwcZ08HbFEcaHF+r3lkSZxHIQ650veu6WeG+IVqvW/kJR/U6/E0t
dko7WgZzgpQY1Q==;
Date: Fri, 07 Nov 2025 15:52:26 +0200
Message-Id: <86ikfm9ch1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
(message from Spencer Baugh on Fri, 7 Nov 2025 07:34:12 -0500)
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
<CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: dmitry@HIDDEN, pipcet@HIDDEN, eggert@HIDDEN,
monnier@HIDDEN, 79777 <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: Spencer Baugh <sbaugh@HIDDEN>
> Date: Fri, 7 Nov 2025 07:34:12 -0500
> Cc: Pip Cet <pipcet@HIDDEN>, Stefan Monnier <monnier@HIDDEN>,
> 79777 <at> debbugs.gnu.org, Dmitry Gutov <dmitry@HIDDEN>, eggert@HIDDEN
>
> On Fri, Nov 7, 2025, 7:02 AM Eli Zaretskii <eliz@HIDDEN> wrote:
>
> > Date: Fri, 07 Nov 2025 09:00:50 +0000
> > From: Pip Cet via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >
> > IIUC, this is equivalent to changing a single condition here:
> >
> > diff --git a/src/process.c b/src/process.c
> > index 33d96198573..7368e242c7d 100644
> > --- a/src/process.c
> > +++ b/src/process.c
> > @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int
> read_kbd,
> > &Atemp,
> > (num_pending_connects > 0 ? &Ctemp : NULL),
> > NULL, &timeout, NULL)
> > - <= 0))
> > + <= 0)
> > + || true)
> > {
> > /* It's okay for us to do this and then continue with
> > the loop, since timeout has already been zeroed out. */
>
> That might be so, but it doesn't mean it makes sense to do this. For
> example, why should we call redisplay if there's some input available?
>
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
>
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
>
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
>
> Nope: the bug happens just the same if the sleep-for is replaced with accept-process-output.
I don't see how this affects the conclusion, sorry. You have to
explain more about the root cause. What is your explanation of the
fact that the test case hangs on Windows (well, I can un-hang it with
C-g, but still) even though pselect isn't involved in receiving file
notifications? And if, instead of running the test via load-file, I
insert the code of your test program into *scratch* and the run it by
"M-x eval-region", it doesn't hang at all on MS-Windows (but does hang
on GNU/Linux) -- why? And if I insert (sit-for 1) before the while
loop, it doesn't hang at all -- again, why?
> I have worked closely with this code for a while now and discovered and fixed many bugs in it. So why won't
> you consider my change, even though it's not trivial? wait_reading_process_output has lots of bugs. We
> have to allow it to change non-trivially to fix those bugs.
I already explained why. Let me try again:
wait_reading_process_output supports several distinct use cases, each
one of them with its specific requirements and expectations. For
example, the uses which wait for keyboard input expect it to return
immediately as soon as input is available in the keyboard queue. By
contrast, uses which want to read input from sub-processes don't
necessarily expect to return immediately, but tend to let Emacs read
enough input first. And there are other use cases. Therefore,
changes that affect all of the uses without distinction are not
acceptable, since they are likely to break some of the uses.
Besides, until we have a good understanding of the root cause in this
particular case, it is simply wrong to discuss patches. See above.
So let's first have a clear understanding of what happens here and of
the resulting behavior, so that we could explain the behaviors of all
of the variants mentioned above.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 13:06:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 08:06:54 2025
Received: from localhost ([127.0.0.1]:45754 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHMB4-0006rT-BR
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:06:54 -0500
Received: from mail-10628.protonmail.ch ([79.135.106.28]:13305)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHMAz-0006r8-F7
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 08:06:52 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762520802; x=1762780002;
bh=nsJTFKtUkCDba/MKUiMYoIbzGAKzTIMTEJ021XVJyyI=;
h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=TWGv6fPYkGB/nVM+1KbgkYzf3iZ6vjHJrB+hQbm6ErS/3qEGrkrzHja2MqeHkH1t9
ACkBnnsxPKFJXhZsGXJ0BDoEMIx1OstiliN6KtG7/CZYl45tL3+Lw4R6nN7BIlwtjS
ojszfD6y3o7JdZAxRbWt2L5QwflhwFYT0fR2blQxthBrHkSY6/Y301aHY2CnOrbhWx
Wsyy57tqfTKMHg/i0IJTyzl8SVT0gxJap+n0ShttO1q17bx57Vlt/1gJleg2rRHtAX
lbgsQLSOclnHExsaCfovhbsZW6hbFj89Pws559OmYJBIdyqBKWuccJekEnIGtqvUNi
YGVNlM+C8apyw==
Date: Fri, 07 Nov 2025 13:06:39 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87v7jm2drb.fsf@HIDDEN>
In-Reply-To: <86ldki9hla.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: d744bbec28778e33b5c42f1f54dd6256203f67ee
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
Stefan Monnier <monnier@HIDDEN>, dmitry@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 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Fri, 07 Nov 2025 09:00:50 +0000
>> From: Pip Cet via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> IIUC, this is equivalent to changing a single condition here:
>>
>> diff --git a/src/process.c b/src/process.c
>> index 33d96198573..7368e242c7d 100644
>> --- a/src/process.c
>> +++ b/src/process.c
>> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs, int read_kbd,
>> &Atemp,
>> (num_pending_connects > 0 ? &Ctemp : NULL)=
,
>> NULL, &timeout, NULL)
>> - <=3D 0))
>> + <=3D 0)
>> + || true)
>> {
>> /* It's okay for us to do this and then continue with
>> the loop, since timeout has already been zeroed out. *=
/
>
> That might be so, but it doesn't mean it makes sense to do this.
I agree; I only did something that should have equivalent effects to the
original patch.
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
Makes sense to me, I must say: if process_tick changed, we should run
status_notify, whether or not there is other input. The rest is
cosmetics (whether to redisplay, for example).
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
We're failing to run status_notify even though process status has
changed.
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
Interesting. Do any of the patches help?
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
That's incorrect. status_notify calls exec_sentinel, which runs the
sentinel even though Emacs is sleeping in sleep-for.
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
The documentation says:
A sentinel runs only while Emacs is waiting (e.g., for terminal
input, or for time to elapse, or for process output). This avoids the
I think sleep-for counts as "Emacs is waiting for time to elapse".
The manual goes on to recommend that sleep-for be used to ensure
sentinels can run.
> So I think there's more to this than meets the eye, and we should
> understand the problem (such that it is) better before we discuss the
> solutions (if they are needed).
I agree. What I think I understand so far is:
The old logic was this:
1. a process status has changed
2. we check whether the next select will definitely return right away
because input is available
3. if so, wo don't handle the process status change, because we're about
to exit the loop anyway
The problem is that "the next select" doesn't look at the keyboard fd,
but our "check" select does, so what ends up happening is that we skip
the process status change (thinking the next select will do it), but the
next select doesn't exit the loop, because it ignores the keyboard fd.
Just for completeness, there was a thinko in my last patch:
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..099e205344b 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5530,7 +5530,9 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
=20
if (kbd_on_hold_p ())
FD_ZERO (&Atemp);
- else
+ else if (! read_kbd)
+=09 compute_non_keyboard_wait_mask (&Atemp);
+=09 else
compute_input_wait_mask (&Atemp);
=09 compute_write_mask (&Ctemp);
=20
would have been the correct patch, sorry about that.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:58:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:58:10 2025
Received: from localhost ([127.0.0.1]:45738 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHM2c-0006Yj-2e
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:58:10 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:53879)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHM2X-0006YM-ST
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:58:07 -0500
Received: from mail-lf1-f69.google.com ([209.85.167.69])
by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
(Exim 4.98.2) id 1vHM2S-00000001ax5-1BnR for 79777 <at> debbugs.gnu.org;
Fri, 07 Nov 2025 07:58:00 -0500
Received: by mail-lf1-f69.google.com with SMTP id
2adb3069b0e04-57986226b53so552735e87.3
for <79777 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 04:58:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=janestreet.com; s=google; t=1762520279; x=1763125079; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
b=uOSzkPRac5MhNOio5fE88MsA8WEbfSYLcCaAIRPF/oLE2JC2ij2oiAiz6sxM4tlZRS
Vjh/8QYXFyolBApgT5X3qdfaQl8x3HpvYN0kux4TeSPPxk7twhw/z2GlYSzFHuNqifp+
uE/oIhoM2336UrhZnx+5y9HU/iMTFOxQTZyt0=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762520280;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
h=References:In-Reply-To:From:Date:Subject:To:Cc;
b=skS4HXR3FREmRhfry2ub3P2DqBvFJ8IGgklNtx2TWlqJj47fvCDnOe85CRMQLjItn
0+B37mqqz5wclIZNjKLWRJHqxcvHODYNKXpfVXb/T2j/+tXL5YPHVKi7P5rks3WcoM
sqJZClx9xnLBDXy6F7WYexkyELXN6ctVxSOERQBTH4hETG25xV3ZrbMD2o5SH3GXFb
XC0gFeJxd5s37kCX6mkSIP8pk3OdoaC7rJzjbn9w5pblzz9/VCpD1E2D4jI+rzOuOe
fHdAbT6FZBss2D8xy7iMxRAfPbxmOyYqZHz7uzLj80noq4rQWg1IXghyO8WrecNsKq
uJ9s+r2o0yAyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1762520279; x=1763125079;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=u1rHdWt+zYnJLpiwj6cDGa+lRWpSd3Tnrvs//q2SvCo=;
b=bUs9QRTTLNapvm9Krj8iBnGRE/8k6KsNuApJb5u9o4dcH4RzoSkGHHgHhJH/Ywh7wA
0NRo4m6Xp03pS0EqeetwJnJSsH7zDTFMCNmo1uqPcIDsq/ivpaa88MLZa5V8w05xZYgA
S9zM8a7hmcH3wehb7N1ALOwF3/p0VFQdU3AfI4mRLQku3PkTJqdSLu0lxUTU9FTtyrco
kF644iblz4tZ/YQUd2dOxuL2incOtbT/OSeuxhwVyiAXp2MPkCzsdW052Fxln+kLLHVj
R62IEgfGy4QrCWi0b8yqaiqgZnnjZM+FotP3VKHxQBjzrjHVK1TfvIs0Uxv9gr0B+MUn
pUOQ==
X-Gm-Message-State: AOJu0YywFLNv/Qo5S726kS7FSCOgTjSWgGSk8wL1RGY7GTrf3//xnAba
zOiHKfDRPLJuC2KZ/KTMVy+PPNEWizcpv5fhutCZV3dwasN0T9ZVX8ZsYq/JO6vUZvUkKaengzy
9lu76R3ODa2A7j/QXTdoz69xVrYatZtS9LL1ZYg7SZCHjHOexZwnkH4hTsbefV8cb7X1TjqOaym
neCnpmrfpIb5ZNeJA1CeF46HQV+WamzQ==
X-Gm-Gg: ASbGncs73ef2yLpH5xMDszdVmTRXEFvqUKYV1/Uf8FnVZ/OutSpenNefUgdBBpX2RI7
Xg6/LMDim6sQcQvwIZ4x9zttebyCWm4YUZJZG3psHvd+4JNvQs19XlVe1LTRDogEI607pg/qZk+
iOFvwwpUS3Xu27G6W7Ulbi9jooMYf3j4O0gfoMbBiVu+QgPlo90Fy04dc=
X-Received: by 2002:a05:6512:3d04:b0:594:20d3:6ba9 with SMTP id
2adb3069b0e04-59456b7dc63mr1112004e87.23.1762520279001;
Fri, 07 Nov 2025 04:57:59 -0800 (PST)
X-Google-Smtp-Source: AGHT+IFb/z0DAezMhUJLVF9bZJJbaoT9/O65FCM5XkKjkZDAGcVTmq/liSNSNPX5eTKzp7Z+XayxDHXdipG69T+SyFY=
X-Received: by 2002:a05:6512:3d04:b0:594:20d3:6ba9 with SMTP id
2adb3069b0e04-59456b7dc63mr1111988e87.23.1762520278540; Fri, 07 Nov 2025
04:57:58 -0800 (PST)
MIME-Version: 1.0
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
In-Reply-To: <87346qb4jo.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Fri, 7 Nov 2025 07:57:47 -0500
X-Gm-Features: AWmQ_bn8yjyoyXvZ42LOil6mTg7k7EhXZpyuMoUx56AKt1UhadeT6t4l7KZ2pa8
Message-ID: <CAO=BR8MhA2x49GZiK_CNWjdzm5gnAiqFbQuKLVyHkdeSGQqnig@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
To: Pip Cet <pipcet@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000001caef3064300bb5b"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, 79777 <at> debbugs.gnu.org,
Paul Eggert <eggert@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 (---)
--0000000000001caef3064300bb5b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2025, 4:00=E2=80=AFAM Pip Cet <pipcet@HIDDEN> wrote:
> "Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of
> text editors\"" <bug-gnu-emacs@HIDDEN> writes:
>
> > The following patch fixes it, cleaning up an area of troublesome code
> > which has caused a number of recent bugs.
>
> > [2. text/x-patch;
> 0001-Immediately-call-status_notify-on-process-tick.patch]...
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL),
> NULL, &timeout, NULL)
> - <=3D 0))
> + <=3D 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. */
>
> (your patch the simplified the remaining code, but maybe it's easier to
> understand if we go through the logical change first).
>
Yes.
That change looks harmless, but I think it indicates something else in
> the code is incorrect.
>
> > Previously in wait_reading_process_output, if we saw that
> > update_tick !=3D process_tick, we only called status_notify if it
> > wasn't also some other kind of input which would cause
> > status_notify to be called.
>
> I'm not sure I understand this sentence. My impression is that we called
> status_notify in the code above if there was no input available on any
> of the FDs compute_input_wait_mask returned, but the other select used a
> different FD set.
>
Sure sure, this sentence is describing the intention. It mostly works but
didn't quite always work due to the mask difference.
> My initial assessment of the issue is that it's caused by a difference
> > in the select mask calculated by the "if (update_tick !=3D process_tick=
)"
> > branch and the main select mask, which can happen when read_kbd is 0 or
> > in various other cases.
>
> That sounds likely to me.
>
> > When these select masks are different, the "if (update_tick !=3D
> > process_tick)" branch can detect input (in this case from file-notify)
> > which the main select will not see, causing the busy-looping behavior.
>
> Why are the select masks different, though? Wouldn't it suffice to make
> them the same, like this?
>
It would, but this code doesn't do that.
diff --git a/src/process.c b/src/process.c
> index 86e83e58c56..3e58ffb4a7a 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
>
> if (kbd_on_hold_p ())
> FD_ZERO (&Atemp);
> + else if (! read_kbd)
> + compute_non_keyboard_wait_mask (&Available);
> else
> compute_input_wait_mask (&Atemp);
> compute_write_mask (&Ctemp);
>
The mask can be computed in many other different ways too, if you look at
the code.
So this leaves a bunch of other potential bugs latent in the code.
--0000000000001caef3064300bb5b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 7, 2025, 4:00=E2=80=
=AFAM Pip Cet <<a href=3D"mailto:pipcet@HIDDEN">pipcet@protonmai=
l.com</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"Spencer =
Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of text ed=
itors\"" <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_=
blank" rel=3D"noreferrer">bug-gnu-emacs@HIDDEN</a>> writes:<br>
<br>
> The following patch fixes it, cleaning up an area of troublesome code<=
br>
> which has caused a number of recent bugs.<br>
<br>
> [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.=
patch]...<br>
<br>
IIUC, this is equivalent to changing a single condition here:<br>
<br>
diff --git a/src/process.c b/src/process.c<br>
index 33d96198573..7368e242c7d 100644<br>
--- a/src/process.c<br>
+++ b/src/process.c<br>
@@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &Atemp,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (num_pending_connects > 0 ? &Ctemp :=
NULL),<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NULL, &timeout, NULL)<br>
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0))<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| true)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* It's okay for us to=
do this and then continue with<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the loop, sin=
ce timeout has already been zeroed out.=C2=A0 */<br>
<br>
(your patch the simplified the remaining code, but maybe it's easier to=
<br>
understand if we go through the logical change first).<br></blockquote></di=
v></div><div dir=3D"auto"><br></div><div dir=3D"auto">Yes.=C2=A0</div><div =
dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_qu=
ote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
That change looks harmless, but I think it indicates something else in<br>
the code is incorrect.<br>
<br>
> Previously in wait_reading_process_output, if we saw that<br>
> update_tick !=3D process_tick, we only called status_notify if it<br>
> wasn't also some other kind of input which would cause<br>
> status_notify to be called.<br>
<br>
I'm not sure I understand this sentence. My impression is that we calle=
d<br>
status_notify in the code above if there was no input available on any<br>
of the FDs compute_input_wait_mask returned, but the other select used a<br=
>
different FD set.<br></blockquote></div></div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Sure sure, this sentence is describing the intention.=C2=
=A0 It mostly works but didn't quite always work due to the mask differ=
ence.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> My initial assessment of the issue is that it's caused by a differ=
ence<br>
> in the select mask calculated by the "if (update_tick !=3D proces=
s_tick)"<br>
> branch and the main select mask, which can happen when read_kbd is 0 o=
r<br>
> in various other cases.<br>
<br>
That sounds likely to me.<br>
<br>
> When these select masks are different, the "if (update_tick !=3D<=
br>
> process_tick)" branch can detect input (in this case from file-no=
tify)<br>
> which the main select will not see, causing the busy-looping behavior.=
<br>
<br>
Why are the select masks different, though?=C2=A0 Wouldn't it suffice t=
o make<br>
them the same, like this?<br></blockquote></div></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">It would, but this code doesn't do that.=C2=A0=
</div><div dir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_quo=
te gmail_quote_container"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
diff --git a/src/process.c b/src/process.c<br>
index 86e83e58c56..3e58ffb4a7a 100644<br>
--- a/src/process.c<br>
+++ b/src/process.c<br>
@@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (kbd_on_hold_p ())<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FD_ZERO (&Atemp);<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (! read_kbd)<br>
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compute_non_keyboard_wait_mask (&=
amp;Available);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0compute_input_wait_mask (&a=
mp;Atemp);<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 compute_write_mask (&Ctemp);<br></bl=
ockquote></div></div><div dir=3D"auto"></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">The mask can be computed in many other different ways too, =
if you look at the code.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>So this leaves a bunch of other potential bugs latent in the code.</div></=
div>
--0000000000001caef3064300bb5b--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:34:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:34:34 2025
Received: from localhost ([127.0.0.1]:45649 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHLfm-0005Rr-2C
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:34:34 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:52765)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vHLfi-0005RS-Rt
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:34:32 -0500
Received: from mail-lf1-f71.google.com ([209.85.167.71])
by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128)
(Exim 4.98.2) id 1vHLfd-00000001ZKZ-0qoR for 79777 <at> debbugs.gnu.org;
Fri, 07 Nov 2025 07:34:25 -0500
Received: by mail-lf1-f71.google.com with SMTP id
2adb3069b0e04-59427acf790so440170e87.3
for <79777 <at> debbugs.gnu.org>; Fri, 07 Nov 2025 04:34:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=janestreet.com; s=google; t=1762518864; x=1763123664; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
b=1PiPqMdB7jFC4uMdp4gDcBZSrM399/J7ComRmd+5/qDytl+JWrHFVCMaQ1KSeADOuc
5L94GKOMhOySoiD45BAPh88++yMX/axpfjp4reUD1Pd1/U04gGvz8xULeMJ5b+qYZZ3K
qpKKm9cekzJcpkR9B5GnLxNcXL1EgpE6muWtE=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762518865;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
h=References:In-Reply-To:From:Date:Subject:To:Cc;
b=xwm4tsJ8wIO7djjPrdAPa0unK+jDlDfBjugrfWTQeNbWUKwhU/sQ4a8SIDwaAp5+Y
45NJolTlfSgtyM5QVK2y/fgUb0EwwoKf0hbg4dVyqoHDnIKiFuvGDxMXNBACv9SliZ
6v5KoqKsLLIbH7V6Uto4q3qfXsm7v64cHr3znICV7Z92oCm11xb58zvvUvDNrY4EB3
EjFfyKT0qa70HcJu2vXMG/fOMLkvm0h6qgHFkfnkhHqjchexwlM5ud9TRnFbIx9OP4
ICgN/oenugq2CViLUooD9MlgQaLNJh0LxPoEJ0141szsFOlxYh1r1ABcyYEX7FjHIc
1tH/ZZwguLr3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1762518864; x=1763123664;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=VRiadZr4A8X1Q60UMr2deM6s/A/gIDQpimu9BjGmugs=;
b=jdV/G3kIysKKBbdXM8gB9Naqz0TJWK9X+JLGX12NUWP5AcPcpMOinC27Uj09WUhthB
zO+VVxi9C9yGUtyptsAckF2140Ote0guOEOhTH319b3HYaXdQL51L7/6smd8r0vFzzf/
NFY+SJ8ISWTF2lPwf1+Ty43ubScv4ttx65tnj0SU+ATELDTSS9wqpow/9WyfolRvvL2m
ipa2GE9Hx+qi9Q8SmvcOhkKMEP/owz2Z9qn7ExdSdd4c+kZAKKH2gx8p1KffbjnvDf9U
COp3v1fQ7DmYAbBeeA4wnLN9J/R2yxiqlLTfjCPqkgefkp5Bz8mnuK55TFO8TsdSk2uj
R2ow==
X-Forwarded-Encrypted: i=1;
AJvYcCWszxbFATGu2TYq+kQ0DtUS4q6erBMpx5CvBUnVxIeohRtt79UALrtogY2XaF9iDq8uBkff7Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyPpkw74grzo8n2JNE/boVzBNGH/fE18+XZt2mmcqbhn/AuHFyF
PbIKyy66otA1kzo5sYrQLEV0nF5SEAqe4EAcntuM0g7k3higBg/RVOBG4N+oBPkjQH7lBG3eIIP
B/gxbd/QI0qC3RxYqmZjzLwOC8jDztb/s48efK2lGed8gKHpk3ZSmQlppUfN1YMtlMeK2OwJ/1B
u+zP7NMQZ0vnmhcdL5YEtJIxT5UApZqg==
X-Gm-Gg: ASbGncuaRQSqClSvP6WI7vg2jxI5jEX+U2ICEIYEy7Ybh2PBEjjoEwCib4vT4QNRCCM
+lU84OxN1NxGSr9uHOMGPBZHv3CptXestmcSB7pAx7qjP+YtC72GD9VdVyUKm20cq32vbROZls9
nz9yFKYD6mKdQ2321t6+cAEUczdWlXRWX43Q2DISlCuKBJF3P4bwpOf6c=
X-Received: by 2002:a05:6512:6d3:b0:57d:1082:e103 with SMTP id
2adb3069b0e04-59456b5b691mr860024e87.16.1762518863891;
Fri, 07 Nov 2025 04:34:23 -0800 (PST)
X-Google-Smtp-Source: AGHT+IG4tOcJKY/OUQvUumvPghXLUZe3fH1gSQudn9wXYDmvdSKmlwi72f0N9rnJ+gc1qGfLFJs+JGjGEx2ELHfk+bs=
X-Received: by 2002:a05:6512:6d3:b0:57d:1082:e103 with SMTP id
2adb3069b0e04-59456b5b691mr860012e87.16.1762518863421; Fri, 07 Nov 2025
04:34:23 -0800 (PST)
MIME-Version: 1.0
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
<86ldki9hla.fsf@HIDDEN>
In-Reply-To: <86ldki9hla.fsf@HIDDEN>
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Fri, 7 Nov 2025 07:34:12 -0500
X-Gm-Features: AWmQ_blVzi6te1Wea-FA157tocCbcXo3fNFWSSmUwtKJEqjRqWuvjme0v0ukGq8
Message-ID: <CAO=BR8Mu2FzVpjgTiu6Kd9aO5rDEB=nvxUA42koHqRVA8=CnYA@HIDDEN>
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary="000000000000c3b1c2064300667a"
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, Pip Cet <pipcet@HIDDEN>,
eggert@HIDDEN, Stefan Monnier <monnier@HIDDEN>,
79777 <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 (---)
--000000000000c3b1c2064300667a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Nov 7, 2025, 7:02=E2=80=AFAM Eli Zaretskii <eliz@HIDDEN> wrote:
> > Date: Fri, 07 Nov 2025 09:00:50 +0000
> > From: Pip Cet via "Bug reports for GNU Emacs,
> > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> >
> > IIUC, this is equivalent to changing a single condition here:
> >
> > diff --git a/src/process.c b/src/process.c
> > index 33d96198573..7368e242c7d 100644
> > --- a/src/process.c
> > +++ b/src/process.c
> > @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit,
> int nsecs, int read_kbd,
> > &Atemp,
> > (num_pending_connects > 0 ? &Ctemp : NULL=
),
> > NULL, &timeout, NULL)
> > - <=3D 0))
> > + <=3D 0)
> > + || true)
> > {
> > /* It's okay for us to do this and then continue with
> > the loop, since timeout has already been zeroed out. =
*/
>
> That might be so, but it doesn't mean it makes sense to do this. For
> example, why should we call redisplay if there's some input available?
>
> (The original patch also removed the call to thread_select, which
> makes even less sense.)
>
> I actually don't think I understand the root cause(s) of the original
> bug. What exactly causes wait_reading_process_output loop
> indefinitely because there's a single (AFAIU) file notification?
> Also, on MS-Windows the file notifications don't work via
> pselect-testing of file descriptors, but the test case hangs anyway.
>
> I think what we see happens because sleep-for is meant to sleep
> unconditionally, and the process sentinel is only run when Emacs is
> idle (and not sleeping in sleep-for). Thus, the while loop at the end
> of the test program prevents Emacs from running the sentinel. In
> which case what we see is the expected and documented behavior, not a
> bug at all.
Nope: the bug happens just the same if the sleep-for is replaced with
accept-process-output.
I have worked closely with this code for a while now and discovered and
fixed many bugs in it. So why won't you consider my change, even though
it's not trivial? wait_reading_process_output has lots of bugs. We have
to allow it to change non-trivially to fix those bugs.
--000000000000c3b1c2064300667a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><br><br><div class=3D"gmail_quote gmail_quote_container" =
dir=3D"auto"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Nov 7, 2025, 7:0=
2=E2=80=AFAM Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN">eliz@HIDDEN=
</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> Date: Fri, 07 =
Nov 2025 09:00:50 +0000<br>
> From:=C2=A0 Pip Cet via "Bug reports for GNU Emacs,<br>
>=C2=A0 the Swiss army knife of text editors" <<a href=3D"mailto=
:bug-gnu-emacs@HIDDEN" target=3D"_blank" rel=3D"noreferrer">bug-gnu-emacs@=
gnu.org</a>><br>
> <br>
> IIUC, this is equivalent to changing a single condition here:<br>
> <br>
> diff --git a/src/process.c b/src/process.c<br>
> index 33d96198573..7368e242c7d 100644<br>
> --- a/src/process.c<br>
> +++ b/src/process.c<br>
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit=
, int nsecs, int read_kbd,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&Atemp,<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(num_pending_connects > 0 ? &am=
p;Ctemp : NULL),<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0NULL, &timeout, NULL)<br>
> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0))<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <=3D 0)<br>
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|| true)<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/* It's okay=
for us to do this and then continue with<br>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the loop=
, since timeout has already been zeroed out.=C2=A0 */<br>
<br>
That might be so, but it doesn't mean it makes sense to do this.=C2=A0 =
For<br>
example, why should we call redisplay if there's some input available?<=
br>
<br>
(The original patch also removed the call to thread_select, which<br>
makes even less sense.)<br>
<br>
I actually don't think I understand the root cause(s) of the original<b=
r>
bug.=C2=A0 What exactly causes wait_reading_process_output loop<br>
indefinitely because there's a single (AFAIU) file notification?<br>
Also, on MS-Windows the file notifications don't work via<br>
pselect-testing of file descriptors, but the test case hangs anyway.<br>
<br>
I think what we see happens because sleep-for is meant to sleep<br>
unconditionally, and the process sentinel is only run when Emacs is<br>
idle (and not sleeping in sleep-for).=C2=A0 Thus, the while loop at the end=
<br>
of the test program prevents Emacs from running the sentinel.=C2=A0 In<br>
which case what we see is the expected and documented behavior, not a<br>
bug at all.</blockquote></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Nope: the bug happens just the same if the sleep-for is replaced with acce=
pt-process-output.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>I have worked closely with this code for a while now and discovered and fi=
xed many bugs in it.=C2=A0 So why won't you consider my change, even th=
ough it's not trivial?=C2=A0 wait_reading_process_output has lots of bu=
gs.=C2=A0 We have to allow it to change non-trivially to fix those bugs.</d=
iv><div class=3D"gmail_quote gmail_quote_container" dir=3D"auto"></div></di=
v>
--000000000000c3b1c2064300667a--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 12:02:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 07:02:10 2025
Received: from localhost ([127.0.0.1]:45581 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHLAP-0001Uv-LS
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:02:10 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:47482)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHLAM-0001Uc-Be
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 07:02:07 -0500
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1vHLAD-0008Vd-Kp; Fri, 07 Nov 2025 07:01:57 -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=WNzSDKuzUKThL/Y7CyqimaitbHs6LjOFMH/0PLbAycA=; b=IqbH233E2Qpo
X3svA7nHrQA7mAlfCjjFz26zAbrtvMs30LYZ2tjAZw1Y+RfizQt5uKmac2fj+M2oI0pjx62b50Jp1
LmUOgkjJ7rHx4PqdxK86RwVSrJ5hTxBil6TY+rIikDg4RxZOs29ilb11YIX1eA6j1XYRH3iwPNWdk
zNhD+C0KTd5r7RAxDrPhNHoPHspHx7yHzlRpZXZiCFBZQZoWxQhJcq8fXcpVf6gnZ1Wt4ZZJjq00N
hD0hUh8YOPFW9rVJkPGcg3ospyJ3yWvRATsx6TXr3PR51g6MJAQvN8IB3lUPq7vu1RywJ8swdE8tp
HpWx+VFAuYj/5a8I60TL7A==;
Date: Fri, 07 Nov 2025 14:01:53 +0200
Message-Id: <86ldki9hla.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87346qb4jo.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN> <87346qb4jo.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: sbaugh@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@HIDDEN,
dmitry@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 (---)
> Date: Fri, 07 Nov 2025 09:00:50 +0000
> From: Pip Cet via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> IIUC, this is equivalent to changing a single condition here:
>
> diff --git a/src/process.c b/src/process.c
> index 33d96198573..7368e242c7d 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
> &Atemp,
> (num_pending_connects > 0 ? &Ctemp : NULL),
> NULL, &timeout, NULL)
> - <= 0))
> + <= 0)
> + || true)
> {
> /* It's okay for us to do this and then continue with
> the loop, since timeout has already been zeroed out. */
That might be so, but it doesn't mean it makes sense to do this. For
example, why should we call redisplay if there's some input available?
(The original patch also removed the call to thread_select, which
makes even less sense.)
I actually don't think I understand the root cause(s) of the original
bug. What exactly causes wait_reading_process_output loop
indefinitely because there's a single (AFAIU) file notification?
Also, on MS-Windows the file notifications don't work via
pselect-testing of file descriptors, but the test case hangs anyway.
I think what we see happens because sleep-for is meant to sleep
unconditionally, and the process sentinel is only run when Emacs is
idle (and not sleeping in sleep-for). Thus, the while loop at the end
of the test program prevents Emacs from running the sentinel. In
which case what we see is the expected and documented behavior, not a
bug at all.
So I think there's more to this than meets the eye, and we should
understand the problem (such that it is) better before we discuss the
solutions (if they are needed).
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 09:01:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 04:01:10 2025
Received: from localhost ([127.0.0.1]:45115 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vHILF-0002eu-Ju
for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 04:01:09 -0500
Received: from mail-10628.protonmail.ch ([79.135.106.28]:57175)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1vHILA-0002eB-ET
for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 04:01:07 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1762506056; x=1762765256;
bh=rCUcPKUImVdBsQIyFH9DmSBCDGjYibj58DTSjOnICV0=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=rK6UYuXEBESXJ6Bw8Dt3ghNhEmnTO87d4F4Lsh1YWTrbC0vonCrGehGkN7MhEPq5Q
7OReyYFY2hUIcOPAgQ1u3wJwXsWyhYlBoQYQ0mQRYL9+2THy2XaunVi6Ew3AyXRc1u
/Vu6S8vLMa4atscuJQuV2fMs5iYYtW7OMMoXkLHgybMFrkZjxbsph7fKiOawXGKd07
Hv4IziRreMKRzne26oBMBWh6GiKvSeL/9MO3bNExWO08XcRIKSiFckPNObvmebKLhf
MEzNwBUQXE9zJh9dEbCNI6Ws3NJzSWeyubgwAWsS6th/elnhkbiDeV5oXpSSmKmi1z
glK4TZZyOUEBA==
Date: Fri, 07 Nov 2025 09:00:50 +0000
To: 79777 <at> debbugs.gnu.org, Spencer Baugh <sbaugh@HIDDEN>,
Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79777: 31.0.50;
wait_reading_process_output with read_kbd=0 can spin forever
Message-ID: <87346qb4jo.fsf@HIDDEN>
In-Reply-To: <ier5xbm7r9j.fsf@HIDDEN>
References: <ierseeqyjdj.fsf@HIDDEN>
<ier5xbm7r9j.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 3540d4194295e236259d526d37ae84f20db63175
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79777
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 (-)
"Spencer Baugh via \"Bug reports for GNU Emacs, the Swiss army knife of tex=
t editors\"" <bug-gnu-emacs@HIDDEN> writes:
> The following patch fixes it, cleaning up an area of troublesome code
> which has caused a number of recent bugs.
> [2. text/x-patch; 0001-Immediately-call-status_notify-on-process-tick.pat=
ch]...
IIUC, this is equivalent to changing a single condition here:
diff --git a/src/process.c b/src/process.c
index 33d96198573..7368e242c7d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5475,7 +5475,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
&Atemp,
(num_pending_connects > 0 ? &Ctemp : NULL),
NULL, &timeout, NULL)
- <=3D 0))
+ <=3D 0)
+ || true)
{
/* It's okay for us to do this and then continue with
the loop, since timeout has already been zeroed out. */
(your patch the simplified the remaining code, but maybe it's easier to
understand if we go through the logical change first).
That change looks harmless, but I think it indicates something else in
the code is incorrect.
> Previously in wait_reading_process_output, if we saw that
> update_tick !=3D process_tick, we only called status_notify if it
> wasn't also some other kind of input which would cause
> status_notify to be called.
I'm not sure I understand this sentence. My impression is that we called
status_notify in the code above if there was no input available on any
of the FDs compute_input_wait_mask returned, but the other select used a
different FD set.
> My initial assessment of the issue is that it's caused by a difference
> in the select mask calculated by the "if (update_tick !=3D process_tick)"
> branch and the main select mask, which can happen when read_kbd is 0 or
> in various other cases.
That sounds likely to me.
> When these select masks are different, the "if (update_tick !=3D
> process_tick)" branch can detect input (in this case from file-notify)
> which the main select will not see, causing the busy-looping behavior.
Why are the select masks different, though? Wouldn't it suffice to make
them the same, like this?
diff --git a/src/process.c b/src/process.c
index 86e83e58c56..3e58ffb4a7a 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5530,6 +5530,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
=20
if (kbd_on_hold_p ())
FD_ZERO (&Atemp);
+=09 else if (! read_kbd)
+=09 compute_non_keyboard_wait_mask (&Available);
else
compute_input_wait_mask (&Atemp);
=09 compute_write_mask (&Ctemp);
That appears to fix the test case here, too, and it's a minor change (if
one that should still be documented, and the code should be cleaned up
to share code for calculating the wait masks, and we still haven't
fixed it for ttys where one "maybe_quit ()" call isn't enough, etc.).
But if a minimal change is desired, I think that two-liner might do.
Pip
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.Received: (at 79777) by debbugs.gnu.org; 7 Nov 2025 08:15:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Nov 07 03:15:02 2025 Received: from localhost ([127.0.0.1]:44989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vHHcc-0000en-GX for submit <at> debbugs.gnu.org; Fri, 07 Nov 2025 03:15:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:33604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vHHca-0000e7-2S for 79777 <at> debbugs.gnu.org; Fri, 07 Nov 2025 03:15:01 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1vHHcU-00042r-1y; Fri, 07 Nov 2025 03:14:54 -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=qtI3Pz+cEbIkafEQX3FU3rycu22UrSFRBcffY5i+4Pg=; b=dci4myWSiCM8 meFZl5lMoURITH10hYGt571wO1MK9Xo894wULk3wV+cTlpzkggTZPcS1c7TU1szmP8EOEkS6I3NbO nqbmeS3uMA1IdxdPT48AFFDgnzVqav6o9kJcgvrY/gREz9SH7Hi7afF2q/KHyBOlDos5zJ2P2ZGcp ieBy2vBrKTWJE5QvBwe7joyaD8e5SJEMhRWJ1YbM1EHPIu/mLP/RbPvZzsScF5u2zyCEhQ1ZXz0F4 O8NJqZtqv9jCFxixYD2eo1CI0GHgbSI44G5hNstRZMd4Bo2YOmvrIjIFPkgX86aFcclFD8AukeYNm /7aJssOYOItmAe+YElW/IQ==; Date: Fri, 07 Nov 2025 10:14:50 +0200 Message-Id: <86tsz69s3p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier5xbm7r9j.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever References: <ierseeqyjdj.fsf@HIDDEN> <ier5xbm7r9j.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79777 Cc: dmitry@HIDDEN, 79777 <at> debbugs.gnu.org, eggert@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 (---) > Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN> > Date: Thu, 06 Nov 2025 17:03:36 -0500 > From: Spencer Baugh via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > The following patch fixes it, cleaning up an area of troublesome code > which has caused a number of recent bugs. Sorry, this is too radical for my palate, given the obscure bugs that the current code triggers. Please try coming up with a less drastic changes, or maybe with more specific conditions for the changes. This code is too delicate and handles too many different use cases, so only very small and localized/case-specific changes should be done in it. Thanks.
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at 79777) by debbugs.gnu.org; 6 Nov 2025 22:03:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 06 17:03:46 2025
Received: from localhost ([127.0.0.1]:41371 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vH853-0003hu-WB
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 17:03:46 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58091)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vH850-0003hm-77
for 79777 <at> debbugs.gnu.org; Thu, 06 Nov 2025 17:03:44 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: 79777 <at> debbugs.gnu.org
Subject: Re: bug#79777: 31.0.50; wait_reading_process_output with read_kbd=0
can spin forever
In-Reply-To: <ierseeqyjdj.fsf@HIDDEN>
(Spencer Baugh's message of "Thu, 06 Nov 2025 15:51:52 -0500")
References: <ierseeqyjdj.fsf@HIDDEN>
Date: Thu, 06 Nov 2025 17:03:36 -0500
Message-ID: <ier5xbm7r9j.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762466616;
bh=I1MCqDDlst2iAcIGuHVOxHFQeGiyUFwgm1btsQhcy58=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=eaSrq01we9uLBFuxth8ZJ6fO7yUQ5tOK3uezvCkR3KvuX78pKLPqCb+8IrqO8tSdw
Dvd49Mq5Dg3XjhMYo2XESDv5VVx41KGs/pVYMgs5kCW6JeWBj7mjv5U2YcOT+g1aNl
6uCujvRizwlLjDPh8EPWz6U9zpU6mtPlBmvtXZIB1IkoaJAPuypN6fLoyHKrJvU9BK
1QqyfuCypdijP1O78LnKHexwkY1lePx78ED04T5VtmU27hKRCO5K2f0P3kaMCrZ/kL
gQpsLxQeENeK7RbM3cXueRD2Xt8NPTK7ubQdzt40kCNk09YvDrnKDe9SJgZJKP/se2
lsZDKoX5Ifj9g==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79777
Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@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 (---)
--=-=-=
Content-Type: text/plain
The following patch fixes it, cleaning up an area of troublesome code
which has caused a number of recent bugs.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Immediately-call-status_notify-on-process-tick.patch
From f4b0faabdd226aad03ce382ec0f967bd7c661298 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 28 Aug 2025 17:06:56 -0400
Subject: [PATCH] Immediately call status_notify on process tick
Previously in wait_reading_process_output, if we saw that
update_tick != process_tick, we only called status_notify if it
wasn't also some other kind of input which would cause
status_notify to be called.
Now, unconditionally call status_notify if update_tick !=
process_tick. This is just as good, and deletes some code which
has repeatedly been buggy for no benefit.
* src/process.c (wait_reading_process_output): Always call
status_notify on process status change. (bug#79777)
---
src/process.c | 41 +++++++----------------------------------
1 file changed, 7 insertions(+), 34 deletions(-)
diff --git a/src/process.c b/src/process.c
index a9d66555f70..6e539f4c33d 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5519,43 +5519,16 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (read_kbd < 0 && kbd_is_ours ())
set_waiting_for_input (&timeout);
- /* If status of something has changed, and no input is
- available, notify the user of the change right away. After
- this explicit check, we'll let the SIGCHLD handler zap
- timeout to get our attention. */
+ /* If status of something has changed, notify the user of the
+ change right away. */
if (update_tick != process_tick)
{
- fd_set Atemp;
- fd_set Ctemp;
-
- if (kbd_on_hold_p ())
- FD_ZERO (&Atemp);
- else
- compute_input_wait_mask (&Atemp);
- compute_write_mask (&Ctemp);
-
- /* If a process status has changed, the child signal pipe
- will likely be readable. We want to ignore it for now,
- because otherwise we wouldn't run into a timeout
- below. */
- int fd = child_signal_read_fd;
- eassert (fd < FD_SETSIZE);
- if (0 <= fd)
- FD_CLR (fd, &Atemp);
-
timeout = make_timespec (0, 0);
- if ((thread_select (pselect, max_desc + 1,
- &Atemp,
- (num_pending_connects > 0 ? &Ctemp : NULL),
- NULL, &timeout, NULL)
- <= 0))
- {
- /* It's okay for us to do this and then continue with
- the loop, since timeout has already been zeroed out. */
- clear_waiting_for_input ();
- got_some_output = status_notify (NULL, wait_proc);
- if (do_display) redisplay_preserve_echo_area (13);
- }
+ /* It's okay for us to do this and then continue with
+ the loop, since timeout has already been zeroed out. */
+ clear_waiting_for_input ();
+ got_some_output = status_notify (NULL, wait_proc);
+ if (do_display) redisplay_preserve_echo_area (13);
}
/* Don't wait for output from a non-running process. Just
--
2.43.7
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Nov 2025 20:52:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Nov 06 15:52:11 2025
Received: from localhost ([127.0.0.1]:40826 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vH6xm-00083W-LP
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 15:52:11 -0500
Received: from lists.gnu.org ([2001:470:142::17]:44748)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xh-00081y-4x
for submit <at> debbugs.gnu.org; Thu, 06 Nov 2025 15:52:09 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xb-0004dF-C1
for bug-gnu-emacs@HIDDEN; Thu, 06 Nov 2025 15:51:59 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <sbaugh@HIDDEN>)
id 1vH6xY-0000vv-5Y
for bug-gnu-emacs@HIDDEN; Thu, 06 Nov 2025 15:51:58 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; wait_reading_process_output with read_kbd=0 can spin forever
X-Debbugs-Cc: Dmitry Gutov <dmitry@HIDDEN>, Paul Eggert <eggert@HIDDEN>
Date: Thu, 06 Nov 2025 15:51:52 -0500
Message-ID: <ierseeqyjdj.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762462314;
bh=H9UzD1+EiEp8yu3iWRMT4MMCL1QlXjmiB62Fqd/QpSY=;
h=From:To:Subject:Date;
b=hqkVzIRCu/X+bv+PDqZwZxqZSqOF6eAU6q895CU2j8Ffe+2ekW73GK0IIJvv7xdBh
TZh3oVKwDn3ywrBqgb+UnvKtXwLPCtPmjmMXo0Y10+mySSr6A8JKeDu7PAiaXdPtSu
5S2KTW1x3TEq/S0oFlTQYt75u1m3BMtIPrDeBWD9mZLn7T4T8FZxd4t/hOvZ+Cs6CT
jKBbsWpMRUKHl9cPbd5hYl5TR3aE45fI7KqEmnszKJLrgxlRm3ZkhxeXjO4mwzr3Xi
qXW1Knk7yCRMdn5WFmVTDsipQa2SlQ5METwebjlsScBrFL3PFDQBe0j/FsCYhhpzKL
kxaPWeDNacmNw==
Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@HIDDEN;
helo=mxout5.mail.janestreet.com
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
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: -0.1 (/)
Run the following Lisp in emacs -Q (batch or interactive):
;; -*- lexical-binding: t; -*-
(require 'filenotify)
(defvar exited nil)
(setq myproc
(make-process
:name "proc"
:command '("sleep" ".1")
:sentinel (lambda (proc status)
(setq exited t)
(message "sentinel %s %s" proc status))))
(write-region "val1" nil "/tmp/somefile")
(file-notify-add-watch
"/tmp/somefile" '(change)
(lambda (event) (message "file-notify watch event %s" event)))
(write-region "val2" nil "/tmp/somefile")
(while (not exited)
(message "sleeping")
(sleep-for 1))
Emacs will hang forever, despite the fact that the process has exited
and the sentinel should have set "exited" to t. While it's hanging,
it's busy-looping at 100% CPU in wait_reading_process_output.
If you comment out the file-notify-add-watch, Emacs will not hang, as
expected.
My initial assessment of the issue is that it's caused by a difference
in the select mask calculated by the "if (update_tick != process_tick)"
branch and the main select mask, which can happen when read_kbd is 0 or
in various other cases.
When these select masks are different, the "if (update_tick !=
process_tick)" branch can detect input (in this case from file-notify)
which the main select will not see, causing the busy-looping behavior.
I'll work on a fix.
In GNU Emacs 31.0.50 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.15.12, Xaw scroll bars) of 2025-11-06 built on
igm-qws-u22796a
Repository revision: 75e93b831c2f3f6e58e9e21c2d1ddbd52a7cd912
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)
Configured using:
'configure --with-x-toolkit=lucid --without-gpm --without-gconf
--without-selinux --without-imagemagick --with-modules --with-gif=no
--with-cairo --with-rsvg --without-compress-install --with-tree-sitter
--enable-checking=yes,glyphs --enable-check-lisp-object-type
'CFLAGS=-O0 -g3''
Configured features:
CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LIBSYSTEMD
LIBXML2 MODULES NATIVE_COMP NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP
SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER X11 XDBE XIM
XINERAMA XINPUT2 XPM XRANDR LUCID ZLIB
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
global-eldoc-mode: t
eldoc-mode: t
show-paren-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
minibuffer-nonselected-mode: t
minibuffer-regexp-mode: t
line-number-mode: t
indent-tabs-mode: t
transient-mark-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
Load-path shadows:
None found.
Features:
(shadow sort mail-extr compile comint ansi-osc ansi-color ring dabbrev
emacsbug lisp-mnt message mailcap yank-media puny dired dired-loaddefs
rfc822 mml mml-sec password-cache epa derived epg rfc6068 epg-config
gnus-util text-property-search time-date subr-x mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader sendmail mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils comp-run
bytecomp byte-compile comp-common rx warnings icons cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify dynamic-setting system-font-setting
font-render-setting cairo x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames native-compile emacs)
Memory information:
((conses 16 67987 11368) (symbols 48 6932 0) (strings 32 19206 2060)
(string-bytes 1 603186) (vectors 16 11217)
(vector-slots 8 154585 8920) (floats 8 28 8) (intervals 56 287 0)
(buffers 1064 11))
Spencer Baugh <sbaugh@HIDDEN>:dmitry@HIDDEN, eggert@HIDDEN, bug-gnu-emacs@HIDDEN.
Full text available.dmitry@HIDDEN, eggert@HIDDEN, bug-gnu-emacs@HIDDEN:bug#79777; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.