Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 11:18:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 05 07:18:40 2025
Received: from localhost ([127.0.0.1]:52110 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uuUSl-0003EF-Mn
for submit <at> debbugs.gnu.org; Fri, 05 Sep 2025 07:18:40 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49132)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uuUSe-0003Dn-WB
for 79367 <at> debbugs.gnu.org; Fri, 05 Sep 2025 07:18:36 -0400
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 1uuUSU-0001QK-Ps; Fri, 05 Sep 2025 07:18:22 -0400
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=Z/L5M6RREG3cKParv7WoOMjXrc989jGRsTKTDQNF41A=; b=q7jqK1s1ymhq
Qby5XVzKdyhbsOEU1M5pQqo9/0hS0q0kEyMFs3YufSlMaUIO6ADRZ4ZzJQO45ebFLtQS/Sh2NAEXX
DmBUI2FOGioq2VN9C831EBl3OBdY7CiZBcVX6Bn/wblUMROPxwB45xeCzZr9XctDBHrH7DJ9ZDQ1p
8JeiDzl7BYwyEUyqMlCYnQUA89k/3rvJepHHVhZ0ICYgW8eRKy26yJ5WSHTMwCLvOkdLP5kNdxApG
iLoEJ/ROciqbKCCI4ptq0Zww2cri7Ies79OLCPTZumaphaJ5+q/B75awROcJHDgGD3/rZgpL0uYNR
2HU+TALpS6g9tR/6XJy3Gg==;
Date: Fri, 05 Sep 2025 14:18:07 +0300
Message-Id: <86ldmti1w0.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: i@HIDDEN, sbaugh@HIDDEN, dmitry@HIDDEN
In-Reply-To: <86o6rpi3jy.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 05
Sep 2025 13:42:09 +0300)
Subject: Re: bug#79367: 31.0.50;
magit-commit sometimes doesn't work if diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN>
<ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN>
<ierjz2ei31b.fsf@HIDDEN> <86zfbahvka.fsf@HIDDEN>
<iera53ahv6x.fsf@HIDDEN> <86wm6digvw.fsf@HIDDEN>
<xifv7wms79gznl.fsf@HIDDEN> <86o6rpi3jy.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: 79367 <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: i@HIDDEN, sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org
> Date: Fri, 05 Sep 2025 13:42:09 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > From: Zhengyi Fu <i@HIDDEN>
> > Cc: Spencer Baugh <sbaugh@HIDDEN>, i@HIDDEN,
> > 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
> > Date: Fri, 05 Sep 2025 14:51:42 +0800
> >
> > > I feel that we are splitting hair, so I went ahead and installed the
> > > last agreed-to version of the patch.
> >
> > I got an assertion failure when testing the latest master.
>
> What is the recipe for reproducing this?
Also, does the below fix the problem?
diff --git a/src/process.c b/src/process.c
index fa003c2..e39e02f 100644
--- a/src/process.c
+++ b/src/process.c
@@ -4831,7 +4831,11 @@ deactivate_process (Lisp_Object proc)
/* Beware SIGCHLD hereabouts. */
for (i = 0; i < PROCESS_OPEN_FDS; i++)
- close_process_fd (&p->open_fd[i]);
+ {
+ close_process_fd (&p->open_fd[i]);
+ fd_callback_info[p->open_fd[i]].thread = NULL;
+ fd_callback_info[p->open_fd[i]].waiting_thread = NULL;
+ }
inchannel = p->infd;
eassert (inchannel < FD_SETSIZE);
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 10:42:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 05 06:42:25 2025 Received: from localhost ([127.0.0.1]:51954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuTtg-0001CR-Oh for submit <at> debbugs.gnu.org; Fri, 05 Sep 2025 06:42:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42180) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uuTtd-0001C5-09 for 79367 <at> debbugs.gnu.org; Fri, 05 Sep 2025 06:42:22 -0400 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 1uuTtV-00065g-Us; Fri, 05 Sep 2025 06:42:13 -0400 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=kV3r/60ukrC3y1z7NLoyuvIwIXtPPgDamoVVg++qrM0=; b=dv4drpG4DEfK HJur8TreHGfPMsQBaowrTgHCJcf9gFf9RQlTYkq1CNmr2VoY2JfNDf8MQ/Dd7lQAssgq58VBbMvhx itMLxxTReCL0vbhabi7ODfoxlzrLcUMryPAFSWA6iKFZ8l1+Mdm2FOXBrvX7+PCrtenCn+OVakVqp WyjJS+R/M4lHRdLezlFePlujKpzlhum8Wkz8MSqfDlQqrFGl66SFxuU+RaQw9cm7A7WEqnIX3pzDF 84Rasc9BlBjv6036RjMSaOaroURzVdNq0hJx2Kf75+ZeJtRcmfG+D43odRdqpTDjgMv1OIay9aDgx 8+P5DnBDL399CCbRRHUyfA==; Date: Fri, 05 Sep 2025 13:42:09 +0300 Message-Id: <86o6rpi3jy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Zhengyi Fu <i@HIDDEN> In-Reply-To: <xifv7wms79gznl.fsf@HIDDEN> (message from Zhengyi Fu on Fri, 05 Sep 2025 14:51:42 +0800) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN> <ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN> <ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN> <ierjz2ei31b.fsf@HIDDEN> <86zfbahvka.fsf@HIDDEN> <iera53ahv6x.fsf@HIDDEN> <86wm6digvw.fsf@HIDDEN> <xifv7wms79gznl.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <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: Zhengyi Fu <i@HIDDEN> > Cc: Spencer Baugh <sbaugh@HIDDEN>, i@HIDDEN, > 79367 <at> debbugs.gnu.org, dmitry@HIDDEN > Date: Fri, 05 Sep 2025 14:51:42 +0800 > > > I feel that we are splitting hair, so I went ahead and installed the > > last agreed-to version of the patch. > > I got an assertion failure when testing the latest master. What is the recipe for reproducing this?
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 10:41:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 05 06:41:21 2025 Received: from localhost ([127.0.0.1]:51945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuTse-00019y-T7 for submit <at> debbugs.gnu.org; Fri, 05 Sep 2025 06:41:21 -0400 Received: from mout.gmx.net ([212.227.17.21]:39469) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <michael.albinus@HIDDEN>) id 1uuTsZ-00019c-Gp for 79367 <at> debbugs.gnu.org; Fri, 05 Sep 2025 06:41:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1757068853; x=1757673653; i=michael.albinus@HIDDEN; bh=Ta/ATF7VtYebxIlNGjBY9pWCRRJUvkgzbxdmA5/oJZ8=; h=X-UI-Sender-Class:From:To:Cc:Subject:In-Reply-To:References:Date: Message-ID:MIME-Version:Content-Type:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=LJmgI7fVYB9qhtNx0p6cyQivCS7vnJlKksAlVmsl+4fUxlJ+dIv6KYy7x7iHX+WV 0eM3PdNnlUJBFu32MfqMKKf8KdpfNYAU+LVuIpaSBWNFumCHV2JO5B0PR6cJRE80d IYU2IwKUE1VO8zgecEIB9YNdPvf0NVhqovhRf1DLM2bUo3URuxpCUw9O00/xaAs8w phK5yfLWhbdHGp/eE2UqXDaqa4Kn3x35+0OYsE14JavT0YXLlm+PBZvzLpr0FyiOG 3AxG5zY2qXIdH4VEI5vDUUDMaPbigyCmr3e/IvN9ehoVMkxML0+bmoD/sr0jbhZjq wfruFsl82MoaadUzQA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from gandalf.gmx.de ([185.89.37.61]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1McY8T-1uKJFA362H-00hlHo; Fri, 05 Sep 2025 12:40:53 +0200 From: Michael Albinus <michael.albinus@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <3aefa906-5bfc-4459-8653-4b2f981fd4b0@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <ierplc7jttx.fsf@HIDDEN> <86ecsmkd6p.fsf@HIDDEN> <3aefa906-5bfc-4459-8653-4b2f981fd4b0@HIDDEN> Date: Fri, 05 Sep 2025 12:40:52 +0200 Message-ID: <87jz2d41xn.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Provags-ID: V03:K1:9FoKcLE9Zjsq0RpYwKXRvxlNwIxYk3YeKVOGvsDFLcq7duMY11M srL+bnxOsplYO2vbw+ujuTls1MStSoVm9CtqnwvQQyUB/kb7MbkAAG4ppJI2/QK0l1OuZbf zLlUhwc42di4knxftZHng5Udfb1D7gU9dgavpVGczaEhLzKWu3NURBIKbCC6CXVoWLKd6Wc eYur/5f1mkMMf9FEk1quA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:dMasWmj2RUM=;DZ+IynfhDAEMrEFGaTq9jyBCfUq 1KAlD1f00OUX0Ek7tL/XMgrrk1S7MmZaFJU7K9Cb4NOPXevQkeTz06hhaBomiIaemdVG3awY1 4KIQ9nU2yNEtvmiK1XuTpWUNnzD3VT6WSxBSybPFc48yXKTsosIl7pa6xGg7cUuiSmUWVNnRd 1Wkdppw++3VNih8YqK94ufAZPQQmUnd/TygGbST/Rhm5M2HXhSmtFincxaB6s7LWK6sY9Qvsf DIvtnsZ539nAh7Z9boKB12+Fq/AU0Bjtm6QM5HFS//ZB5vY6idbDJGpzjlEdRozH8IpVMWKXP qMy33PQzLmnk1A6S0L1nenMrytj84wWUHaJdSVLUnlpb5a5MlMHUpp6h0BI1IUCPl+oUtho/Y MdccJdSZ1T1wfHvvk9RrweQvWZk3uA+hwbSujNAMqnF9aA0l5cF+DnNZ91H/dh02miI8yFf9V cJjhX4u4RnWu0JubiVpW3N2mubgrr66jAVWXT7mg8TLW8c85CN/Til7IuaT7vnoiU5saMlCdh N+vDv/H+bAoj0N2+Hlnzp1Wog6oEDfStiRXdCaAha6yGdW2ySM9Y+s03MdmahiH6KXrZavSpn JV8cAe5yWJAWMp42uOUYlTvmtBXTGbGQtBmw907j/2dAETRXSNsh8KJlRX1j/beSGDcp4nj4R psvgDq1OfG08lP6WXdWOTDBuA2qVjAjShn7K/z4g0WmlM/fTI7+d/h2rMmdxVByyrEkE7OAjf sjikz70ks+1YoyXkkCvmAK5acjOTkodEF3O3VRFa192adk3xOoei9ZJfd+kYXZ02v+SRB42RK rOmjBaYq9o3bRHKNnPQeFo/zrw6gWTb1wuWZgUiQpEMF1j1LyyjfaBqhNWRJNvrgjI6tWwJ6b MmGdcJsOO8dh9scLmxW3F1PmxacuNZ2FPGj3xn5AJ9Gt0a51QYa3UI558KNHnIalVdG4tQkyJ F+3vuisCIY326aTx/SnzpmHdE8rVC+Jggp8ut8E9kfMLAij9gBr/IDQBUTlxmj2eKItDyROV+ TyxmwDN42UNOOFR9/Vl17ZFnulW3PBuW7S/n7yvew3g7T2xStHOYq9k870Uv/2my3GYDtx/eM oGTE2+/CA5B5oGt3Fx9IERNFYaSvmieNbaAzWyUx4GH+RYLhENuvnhvs1kKAs3Zy+N2WO6j0t ALeaUES1Oyu+z4RORFu3L6r2zLlIvJ29Zt/lCIMFCjx/oiAJel0lwNt5Kp7IRIPHxk7ODNTkS jCFbN2PBgvy0AdjvUL/garIdpTshqDrSeDNiVbZ6XMRPsLr9eI0tw7WDxqvVGLuarvvQ1DhzY pM0avInJUAB1knOLc52h90yOO2VWH4JObPJf1sEqRejerqL3A/WV5fzYtkYm7IEpnJd04EKno p0m12njAE3QIftW5knQQsPR/y+gysh2tPRH9/K4nEtehFyTOgaqq9AbSXF9OXRv0H9L4wY83Y gxNNY1Twn4bvdgvoifOkoLyOqBpW0/dPXr1Htm2dMLBr5v6QQsi/q8oIAGVAE1HjyKwGC2piO WRKvr0GIou86sba5J3ly8mr4Zw5UfsNwDxqZvRlC0xVZdLSWI59wyXxcx8T/nM/hQQQOwbgSe ZP/EVuyucRgXWd4fBArYotSkZEQOxSQXunsbUIYljEjsILTimn8ZKR+ADOndiKxFQ3yphxKPy UeBBrsFLWPcNvwRb3IRqzpg5/Jxei4OgVrMTvynmMwuAf6aiWp4L2IQ22os/hOXbvQxKHugyA qaJyTO+NJnXkDPJ/FRXt5iORahcpIh+DLDX8lQ00QdF3OH+NS667/3kOb4F+S5w4BsapGxG8i Rd19bY5txFLpETu06EeLf0AQeFmkpwz4ENuwPYk4Fct3I1k3L8Q5bPMb3NNT4v86y0rVbYReZ gn19bHvKCAosF4fE8RRK53fiZHBHuQSFkpk1RhPkkMlw3iXm1HFCRDn0Et8AGPfeKpLHcbSpu dYdkkE+Rth3rmcGG99x+XSY96N2v3CUvhXlDOWZ//ZX3rBgoo68y0jPwUwWRpkQzhOojQxPHI NRAynsoMjpaAnt/1U8eMiAn9gxgSgQyLor4tpozOapUEdgcXEO0GEjIK9ZUZyIrJp0gQWi3y0 rfXC43w44c7SbC4lGWIMourlprfVlQzdRnccRkra13zU4tdMVG8V37pgdk2zQWR1o8qgs87kf M8NPmfG1xxQrwVZ83eXEcYCetMs8NsS+3pYS/toGMq0c1jXbhgvN6bXsz6kVsF7l5Omr065CF GvrWdJsbEZkcWIKnmV/8UBVLDWgaslCJm2tkGaW/xWb7oD0MgnKtDCcLUcQ1g1l4yroou1Gai U/L5yAtN92UoYzvawHfpGCS3R9neYM79mAewTrPv5e/CnkvX5ACsTAnxMYTx+7ICKV/7FJtB6 5Gld7ZLgCmGOgrNMpEJZSO1y1l97G7F9vHLREqXWesZ0A3g0yQxBBHeJAqcgpns56Ky8rhw2i 59VwbgSMfeRoieOehz682dDUwI1mk7Xqs31qYO6tIs71Eu/dU2qtwn6UGDV/TxyEbnHDYQXj+ RyAuX2eujxFkfS24XN1hMTkBucU3ITT4Q4JDSOjOmh8BWtGDSyH3nts1vEHg1ta8FiIg9oZsT ZERQNO+Hruq1hYAh1H+J3l/gugbeeieiGJ+DgyL/I2czCrczd4lZxF+nW13uiYz7iiNyYm34b 2WxATUc7+cSg67p7krgEYkO8LIitorDMtqj3XgXxj8HUf+VjdnzEIurK53eb/TZocsEKkRh8s wXaM6eDO7nInD9U8dzxTUPJFuuR3yEoEwYOJMj4xm56jmClidXZ1kWq9JxRzTMdso28zN2bAV QgTWBF2VgM1UnH6sU5YrdoV165G0aGjv/PL94/N05LiUkY5EMcNEaG+QD0HjdTPCUs6V6JhV2 Z7lncFwke5YWTH9DqJhcqjmO0DJx3ePAIhN7SNeJ2I+H9KGQdyYvA6dYecBQJ5XCMMBDX/Gua O9huo36+1BiNqW6CcMwqj1QsuqeU3fkAWSBQFAzr6uptEUH5wIUKJAIDsUzUgURXJ8JIaNqnB MXxaXTr5f8ACWMcI0YrVp0rJFCD5Gq0TLUkB5tr9H9vXJ6g7uyUjDwkzZSI48LH7DaGIZ0ouX LSsVyBtc9X+4SBnUYu86/THJa/gves5i7zEC+ZVTXokJ5dGSYbSled9gczRyrO3eiGkpELG7x 3NVZqt/Z59D7iKPHOdNYqRYjotEnVfyqRVFV1hIiDIQfIoP9XjKetpe29ApCnVVZhOQNd2c+u cQO4pe3N+3I6OuxgjgMrmvyp2YDBZTts9LEfF26Gkw3629jJW7YSc1BGjlxxbm4JUzsI7jIRR OiythRjZBGrrPiIfsLwV7xxN46SjTgfmh0gaEJ2viBH+aTI/U6L/+SFI+G2Uonaf9He6ndaCm 9lU9rYAzBrMobm/9mlFFGbFZnwHCv0qevnTSrzJKTGZ6ere/2+Vgf+R64UULPkmtbsPXfeZJU 0KmLqFIvUkJXCVVshnL0ze1CbXQkRGb5kBL0uQr88LZn5zBsfpJtpJ+J4zhax8dzWAMDU1VHI 5D8xm/Q/TsPqMw5toB2YVPiyyerTLNoLDe4HplgKnaItNEvhRBKY3zHfpCdexYTT6D+eD1sOU emAWKnsgMNH2J1Ph7QGYBNOqx2i5XUlIt2kt4HrDl/ZjR8ZSTdczmkBfoScEXRIz8UpSXjWc/ NLd2Be23vz4GFUyRAgKEZ0EdeaYHF25fQcx5DlgyfyI35jllGy41Wcbq2Cpj/xZaGV7UmYiiv 5Tovde5CVqa3yzlofa5LesoJL4fuEk/7f8xtb3kmW6YUwne+Fj0+XePdP5v18GybKGLbYVwDM HzYCYw0oF8DVzWZKjcHPT4ghtKjCH6izvdJU32RJ3lDsgd1rF6m2grp5ay5DZTJxDaC28lODD TwhiNAkKa/a8/bhwfpW3Wv4RNau5Nq2TqqkYd2K+nhvGPMj7B9Afcdp24wSluOb9gzyq+xX2X CKs7Gun2l7sqwF7cmKSkVrHNBaTM/WEe97kNxavVs2wBEZhWIn1k3zcgpmiB1Rr6s9THUYEf9 +otd2qC/6ABwCU5cqUU8Bz+9xsjAWJAsAsZ2jvNOtiO/lyF9vTHDjn7ow21vz9hboQW12Hd1O /IYwYDg792Ee43VVqhCrZnukYtH1VWGG6zsz3RpDv5NUPGYW4cQCida+O1Ka31L7NVOfuMfRj z/KIxa+ftiIO8P3rStutKdVhMhbW1MV7QR2D8QFTTRveaoTZrcWq6cBK5XV/ePw8rQqE+DJgE NUdTpdMepfqEJHzFIFanUvBPLj2TH5LChq6EgmFrzOlmOzz0P8fAVvCExUkq4V7SmxlRv68iv a9GL04MeeLO/OcOYh326r9iAarncoorGkM+nRe7rv/J1uajYTkEMeRHuMdI5sbX/sYeEqa4ot XdXtEQyw2/YwgYbY2y9H3rf1qubB0T5DXM5QMbAgYZL5F1HbF6pTkKDAlI2Xo2ExUSzH5l98q 98phbQPsJ2OyBTVVIgC+wCrrrpld+KQGqkYc/IJtTIPszKGaM2AfZ8kKJs3fyKOeY7utoa+z2 K3OjcubfUlmiAb66xhlyjLuMf+5rVau72O5WYduVloXmDIAIXD/HtmfWv9XwKAsngsp0NAT+q kJFR4GQ7UeFwDydgoNGk0X+rOT6tvjqzhQhHycrAvjv8XvswaC5ghuwzYgvjvPHCfXV6T8K7f MKQMIWISY/0TlslcqS6OexWR/NYhLs6FBA8Pjujdp2l9jWVoF++o+MlBIWo29i1uioTaWXBZa QP09MOJR9rxDjzEJbsemheP/JCe8E/wDSAm0xZlCnF320CEM9GE9nXcATEwFYqccJZqY9oPF1 K5sutXXQwF X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Dmitry Gutov <dmitry@HIDDEN> writes: Hi, > Last I heard, Tramp's branch wasn't stable for everyday use (citing > hangs, IIRC), but it has a set-process-thread call, locking > connection's process to thread explicitly: > > https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/tramp.el?h=feature/tramp-thread-safe#n2759 It's years ago, but AFAIR the knockout for me was bug#32426 (merged with bug#25214). And there are further open thread-related bugs from that time I have marked locally: bug#32487, bug#33135, bug#41220. Best regards, Michael.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 06:52:03 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 05 02:52:03 2025
Received: from localhost ([127.0.0.1]:50756 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uuQIk-0003cT-52
for submit <at> debbugs.gnu.org; Fri, 05 Sep 2025 02:52:02 -0400
Received: from relay4-d.mail.gandi.net ([217.70.183.196]:41395)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <i@HIDDEN>) id 1uuQId-0003bs-Nm
for 79367 <at> debbugs.gnu.org; Fri, 05 Sep 2025 02:52:00 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id E635C443B5;
Fri, 5 Sep 2025 06:51:46 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1;
t=1757055109;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=po79a34z/yO7I1LR4Uhe5iDDYtk5zhXz2t4gPqJvEOM=;
b=c5S7CcQqyuqqOefAkP3EMR85YMMEnmldWcgGMuno6P/1Bq4sfbqAQGVI8XqFdVfxEXkUcR
FN8NOGBck+qPm14FA9GHfDee9R8npW5CbfglzUpDGCKG/1CVNZ4vG3bXMk29caN8FVa8Gb
UNLsJvGLvSAiekqEMVojSiCJcJlV6FFTTvC+h55MOFgE97yWCGgfXnXngC0JCeUvJoGOvt
JFsiOCj0B+JqYiL2C0nWAjLD0ydxo2neP18HGhUltp5US3MDPsEAiF0fvnrX25bCY6QYlc
9tyObV8Ml7lPPSMrHbhyv1REfr1b6+U++EFQaH/ZZgr4aOcX2S2jlwLRil6G7w==
From: Zhengyi Fu <i@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
In-Reply-To: <86wm6digvw.fsf@HIDDEN>
References: <xifv7wplc92x7x.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN>
<ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN>
<ierjz2ei31b.fsf@HIDDEN> <86zfbahvka.fsf@HIDDEN>
<iera53ahv6x.fsf@HIDDEN> <86wm6digvw.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
Date: Fri, 05 Sep 2025 14:51:42 +0800
Message-ID: <xifv7wms79gznl.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdekvdduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhgffffkgggtsehmtderredtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeejledttedugeeviedtkefgvdffgfefleevgfffffeuvdevieejvddvieegffeuvdenucfkphepudelvddrheeirdelledruddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepudelvddrheeirdelledruddvpdhhvghlohepjhgrmhgvshdqfhhuqdhusghunhhtuhdvgedtgedpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeehpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh
X-GND-Sasl: id@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, Spencer Baugh <sbaugh@HIDDEN>, dmitry@HIDDEN,
79367 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)
--=-=-=
Content-Type: text/plain
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
>> Date: Thu, 04 Sep 2025 15:30:30 -0400
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> >> From: Spencer Baugh <sbaugh@HIDDEN>
>> >> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
>> >> Date: Thu, 04 Sep 2025 12:41:04 -0400
>> >>
>> >> Eli Zaretskii <eliz@HIDDEN> writes:
>> >>
>> >> >> We should probably just unconditionally do:
>> >> >> pset_thread (p, ps->thread)
>> >> >> here.
>> >> >
>> >> > That's a bit dangerous, since the I/O descriptors of the new process
>> >> > are not yet set, so the call to pset_thread there, in case ps->thread
>> >> > is non-nil, would do a partial job. We could instead move the
>> >> > pset_thread call to later, where set_proc_thread is called, but I
>> >> > preferred to undo what make_process did ASAP.
>> >>
>> >> I'm confused.
>> >>
>> >> - It's just duplicating what make_process did, so I expect it's
>> >> essentially a no-op, just simpler code.
>> >>
>> >> - Why would it be dangerous even if that wasn't the case? We're still
>> >> setting up this process, it's not visible to any Lisp code, so what
>> >> bad event could even happen?
>> >
>> > Having some part of server_accept_connection, even a small part, run
>> > with the new process locked to a thread introduces a window during
>> > which the process is in an incorrect state, and I would like to avoid
>> > that if possible. Admittedly, in this case the window is very small,
>> > but it is still there. Some future changes could actually trip on
>> > that.
>>
>> It's already locked to a thread by make_process.
>
> I feel that we are splitting hair, so I went ahead and installed the
> last agreed-to version of the patch.
I got an assertion failure when testing the latest master.
--=-=-=
Content-Type: text/plain
Content-Disposition: inline
Thread 1 "emacs" hit Breakpoint 1, die (msg=msg@entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file@entry=0x555555879464 "process.c", line=line@entry=5127) at alloc.c:7302
7302 {
(gdb) bt
#0 die (msg=msg@entry=0x55555588fd38 "!fd_callback_info[p->infd].thread", file=file@entry=0x555555879464 "process.c", line=line@entry=5127) at alloc.c:7302
#1 0x0000555555806a6a in server_accept_connection (channel=14, server=0x555556bce4bd) at process.c:5127
#2 wait_reading_process_output
(time_limit=time_limit@entry=30, nsecs=nsecs@entry=0, read_kbd=read_kbd@entry=-1, do_display=do_display@entry=true, wait_for_cell=wait_for_cell@entry=0x0, wait_proc=wait_proc@entry=0x0, just_wait_proc=0) at process.c:5989
#3 0x00005555555a3188 in sit_for (timeout=<optimized out>, reading=reading@entry=true, display_option=display_option@entry=1) at dispnew.c:6978
#4 0x000055555570b8ba in read_char (commandflag=1, map=map@entry=0x555556aa02b3, prev_event=0x0, used_mouse_menu=used_mouse_menu@entry=0x7fffffffd8bb, end_time=end_time@entry=0x0)
at keyboard.c:2925
#5 0x000055555570e164 in read_key_sequence
(keybuf=keybuf@entry=0x7fffffffda10, prompt=prompt@entry=0x0, dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, disable_text_conversion_p=false) at keyboard.c:11146
#6 0x000055555570feda in command_loop_1 () at keyboard.c:1424
#7 0x00005555557a5ba8 in internal_condition_case (bfun=bfun@entry=0x55555570fcb2 <command_loop_1>, handlers=handlers@entry=0x90, hfun=hfun@entry=0x555555700325 <cmd_error>)
at eval.c:1690
#8 0x00005555556f8b3b in command_loop_2 (handlers=handlers@entry=0x90) at keyboard.c:1163
#9 0x00005555557a5aa7 in internal_catch (tag=tag@entry=0x118e0, func=func@entry=0x5555556f8b14 <command_loop_2>, arg=arg@entry=0x90) at eval.c:1370
#10 0x00005555556f8af1 in command_loop () at keyboard.c:1141
#11 0x00005555556ffdf1 in recursive_edit_1 () at keyboard.c:749
#12 0x0000555555700181 in Frecursive_edit () at keyboard.c:832
#13 0x00005555556f8650 in main (argc=6, argv=<optimized out>) at emacs.c:2629
(gdb) fr 1
#1 0x0000555555806a6a in server_accept_connection (channel=14, server=0x555556bce4bd) at process.c:5127
5127 eassert (!fd_callback_info[p->infd].thread);
(gdb) info locals
buffer = 0x0
contact = 0x555556a903e3
host = 0x30
service = <optimized out>
ps = <optimized out>
p = 0x555556bd4c08
s = 16
saddr = {sa = {sa_family = 1, sa_data = "/run/user/1504"}, in = {sin_family = 1, sin_port = 29231, sin_addr = {s_addr = 1966042741}, sin_zero = "ser/1504"}, in6 = {sin6_family = 1,
sin6_port = 29231, sin6_flowinfo = 1966042741, sin6_addr = {__in6_u = {__u6_addr8 = "ser/150425139/em", __u6_addr16 = {25971, 12146, 13617, 13360, 13618, 13105, 12089, 28005},
__u6_addr32 = {796026227, 875574577, 858862898, 1835347769}}}, sin6_scope_id = 796091233}, un = {sun_family = 1,
sun_path = "/run/user/150425139/emacs/server\000UUU\000\000\000\000\000\000\000\000\000\000\370?UUU\000\000?pUUU\000\000\300\207\272h\000\000\000\000\001", '\000' <repeats 36 times>}}
len = 35
count = <optimized out>
args = {0x7fffffffcf84, 0x55555686ace4, 0xa, 0x5724a633450d2100, 0x7fffffffd190, 0x555555a714e0, 0x555555c2a7f0, 0x0, 0x400000000a000000, 0x400000003f000000, 0x7fffffffd1b0}
nargs = <optimized out>
host_format_in = 0x7fffffffd004
host_format_in6 = 0x7fffffffcfe4
procname_format_in = 0x7fffffffcfc4
procname_format_in6 = 0x7fffffffcfa4
procname_format_default = 0x7fffffffcf84
name = <optimized out>
proc = 0x555556bd4c0d
dash = <optimized out>
nl = <optimized out>
host_string = <optimized out>
open_from = <optimized out>
(gdb) p *p
$3 = {header = {size = 4611686018578444307}, tty_name = 0x0, name = 0x555556b274c4, command = 0x0, filter = 0xef8cc0, sentinel = 0xef74e0, log = 0x0, buffer = 0x0,
childp = 0x555556a903e3, plist = 0x555556a90163, type = 0xd4d0, mark = 0x555556bd4d25, status = 0xf810, decode_coding_system = 0x0, decoding_buf = 0x0, encode_coding_system = 0x0,
encoding_buf = 0x0, write_queue = 0x0, stderrproc = 0x0, thread = 0x5555558eb005 <main_thread+5>, pid = 0, infd = 16, nbytes_read = 0, outfd = 16, open_fd = {16, -1, -1, -1, -1, -1},
tick = 0, update_tick = 0, decoding_carryover = 0, read_output_delay = 0, adaptive_read_buffering = 0, read_output_skip = false, readmax = 65536, kill_without_query = false,
pty_in = false, pty_out = false, inherit_coding_system_flag = false, alive = false, raw_status_new = false, is_non_blocking_client = false, is_server = false, raw_status = 0,
backlog = 0, port = 0, socktype = 0, dns_request = 0x0}
(gdb) p fd_callback_info[16]
$4 = {func = 0x0, data = 0x0, flags = 9, thread = 0x555556c5d598,
waiting_thread = 0x0}
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 5 Sep 2025 05:54:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 05 01:54:25 2025 Received: from localhost ([127.0.0.1]:50550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuPOz-00005T-1M for submit <at> debbugs.gnu.org; Fri, 05 Sep 2025 01:54:25 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46664) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uuPOv-000059-Jv for 79367 <at> debbugs.gnu.org; Fri, 05 Sep 2025 01:54:22 -0400 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 1uuPOo-0000Kx-Ko; Fri, 05 Sep 2025 01:54:14 -0400 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=dr5ZWENIEYqfu6awUyBNdEtEL+f2M0f+DWTSIrUcz2s=; b=rr03ZzYj1lGm 5iLZ6z8NveOn/+zLYZjXR+xhyQ3EsHfq8XBwkx7FLZojUXQqdbsmKUXkkDJHHfg3i6m8RoTiyy9Pj TTl9bw27nOPXwAJTsMn6cj9y8muGdKYl9ddDPOXPki8zNyBdZkOeilJVyouYOglDWkMVDPzl8pfih V9fPVaFeXiJUv61GvqxTiCrcZdGM2xXdXSLNfw7x/DZH+yZfayBY+OCf5/VztRJ1lPOs5cGlOLydl Wc+7v5dTxfftIbusRoH59+TizLBeb+RKLKvolRTgLFTYOZVcbtGtgI9WBFij9fdA0wab/MhdAWm0c pnkwEqPPRGoYnexFTyM3+w==; Date: Fri, 05 Sep 2025 08:54:11 +0300 Message-Id: <86wm6digvw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <iera53ahv6x.fsf@HIDDEN> (message from Spencer Baugh on Thu, 04 Sep 2025 15:30:30 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN> <ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN> <ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN> <ierjz2ei31b.fsf@HIDDEN> <86zfbahvka.fsf@HIDDEN> <iera53ahv6x.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN > Date: Thu, 04 Sep 2025 15:30:30 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> From: Spencer Baugh <sbaugh@HIDDEN> > >> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN > >> Date: Thu, 04 Sep 2025 12:41:04 -0400 > >> > >> Eli Zaretskii <eliz@HIDDEN> writes: > >> > >> >> We should probably just unconditionally do: > >> >> pset_thread (p, ps->thread) > >> >> here. > >> > > >> > That's a bit dangerous, since the I/O descriptors of the new process > >> > are not yet set, so the call to pset_thread there, in case ps->thread > >> > is non-nil, would do a partial job. We could instead move the > >> > pset_thread call to later, where set_proc_thread is called, but I > >> > preferred to undo what make_process did ASAP. > >> > >> I'm confused. > >> > >> - It's just duplicating what make_process did, so I expect it's > >> essentially a no-op, just simpler code. > >> > >> - Why would it be dangerous even if that wasn't the case? We're still > >> setting up this process, it's not visible to any Lisp code, so what > >> bad event could even happen? > > > > Having some part of server_accept_connection, even a small part, run > > with the new process locked to a thread introduces a window during > > which the process is in an incorrect state, and I would like to avoid > > that if possible. Admittedly, in this case the window is very small, > > but it is still there. Some future changes could actually trip on > > that. > > It's already locked to a thread by make_process. I feel that we are splitting hair, so I went ahead and installed the last agreed-to version of the patch.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 22:47:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 18:47:17 2025 Received: from localhost ([127.0.0.1]:49632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuIjc-0001ND-FV for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 18:47:17 -0400 Received: from fhigh-b5-smtp.messagingengine.com ([202.12.124.156]:34495) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1uuIjX-0001Mq-7P for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 18:47:12 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 1CD977A0602; Thu, 4 Sep 2025 18:47:05 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-06.internal (MEProxy); Thu, 04 Sep 2025 18:47:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1757026024; x=1757112424; bh=xszehEW3EcXjL5BPh4zenXMBAmQU/MAQ1ym1DtEBJR0=; b= CYO+IJYjtqw8ZixJeY+3uUj/HF+4REzZaS34GbccOK6j/uty6r5Y+xj7T6OVwgUe VM43AejfSgaTDT2lo6/byp7pxdnrxA2405UnpjBPXpfJwJGMPvoYaesjh1QEg/le Wb8ZWTaxLUi+4Rkw54E68KaiN62y+WrwsQVI08xfyRV2zJwidtVGUqFnyavSLVHJ Io6JQyNx2kb2xTNnxc529i4ehLtkMOo10nZzabLDqRDEZQvA60zqwbii6vRkMRRf f9HU4PrZRwhwoELu3VzVi12l9lmXi3JgDF49gGSjU5CSoYImaxBvYB7YDN/Vizfn taxfaBwN3m9VpaqPAv6f/w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1757026024; x= 1757112424; bh=xszehEW3EcXjL5BPh4zenXMBAmQU/MAQ1ym1DtEBJR0=; b=g PiSiOOpnbV67FDg7n1A+YulZgXDdp4MB/ZkBPzkBLNijqgwlbTsZD5+KwkbX8dJR wF6box9Gtw+vFNOTt0PWvR/btleigViJpnTIb/lbv1stTmn9kpKfUvFTlolHlVOQ /aMZKnIV4M4dsWD1+lepoZ2RlsKgoVifHNhLyUwJwdpvW6nE11FlMF4LN2+j4WRH cPcsA52gHynC5tJrrB3rqouXYgH+hGxOLSCMqcBXs1olHvjsf7POni3OhTn75nVo bqTyG58iGX7BRp6J/eh/bcWG+7uWFxZKt2FpblL2wC2vZVf7P1z67B+FnjdZmdGB JfZVr/7TNj58/niCKdi0w== X-ME-Sender: <xms:6Ba6aBv-xuR3BpS1BauXAQ5HNTU92bQ_KH7RPuzHDUh3NtFwhkcKdQ> <xme:6Ba6aFCB1EnkU58hqaWIAZsHEvS336ZVyn4s_-TttofVxVTs-Q0oCd8c8aIYViN6w -Kv7KjKWl7q8DK8vzk> X-ME-Received: <xmr:6Ba6aBX9iMqVuGPIYmEE_AOYxnyqloYAQio6TS8DeDeWPW4asSEjQbrqvCNZ49xLgFY> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdejvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh ephfegudfftdevhfelveetteehffehvddujedvjeekffeljeetleejieegvedtjedtnecu ffhomhgrihhnpehgnhhurdhorhhgpdhgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdr uggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtoh epvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhr vggvthdrtghomhdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghpthhtohepjeelfe eijeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: <xmx:6Ba6aLDVUYJtmemL6EC93wHtd4yh2Zi9vppyV4hGdD3RfK5syA7dEw> <xmx:6Ba6aM9pqu9Z6VC1o6IYH1ry4Xvv9gRJhNTKXj4Uxo3Oouu37SJuIg> <xmx:6Ba6aKEaXrv6UQ4Pm4F8UEbesIZ6teXrZJyKGQ-Tz5OBvdQX9ddERw> <xmx:6Ba6aCPjlph8HLWcoBROeCBVnCDOEM6maaSfzyZm5YhSrV3_83aHKQ> <xmx:6Ba6aHVwCvef5CN5YHevQyiegNktkzPno9wlXf_GN7Nu-15abSNZn7en> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 4 Sep 2025 18:47:02 -0400 (EDT) Message-ID: <3aefa906-5bfc-4459-8653-4b2f981fd4b0@HIDDEN> Date: Fri, 5 Sep 2025 01:47:00 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <ierplc7jttx.fsf@HIDDEN> <86ecsmkd6p.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86ecsmkd6p.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 04/09/2025 08:18, Eli Zaretskii wrote: >> This is unfortunately not detailed enough to translate into code. I've >> never seen a real-world program which would be vulnerable to this >> problem, as described here. I can make up toy programs which meet this >> description which would hang, but I'm not sure they're actually what >> you're concerned about. Especially because they aren't anything like >> real-world programs. > > I toy program that looks valid and runs in a single-threaded Emacs, > but hangs or fails when run from a non-main thread is already a > problem. Whether it is interesting for us depends on the program. A > toy program which demonstrates an issue that real-world programs will > meet is interesting. A toy program could be a good example if you can choose a specific one and point out how it related to a real program (e.g. being a simplified case). We could take such a program and see whether it indeed exhibits issues multi-threaded (when unlocked) but stays reliable in the single threaded case and multi-threaded when locked. Both aspects seem testable. >> Could you give some more details about the scenario, so I can try to >> write a test demonstrating the problem? Or could you point to a >> real-world program which is vulnerable to this problem, so I can turn it >> into a test? > > I've never used or debugged a real-world program where these aspects > come into play. My experience is almost exclusively with small "toy" > programs and test programs, the ones we have in the test suite and > also those submitted as part of relevant bug reports. You may wish > looking at running the Gnus function that fetches articles from a > separate thread (I think someone tried that at some point), and you > may wish talking to Michael Albinus, who tried using threads in Tramp > (I think he has that on a branch somewhere?). There two are interesting. Last I heard, Tramp's branch wasn't stable for everyday use (citing hangs, IIRC), but it has a set-process-thread call, locking connection's process to thread explicitly: https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/lisp/net/tramp.el?h=feature/tramp-thread-safe#n2759 For Gnus, I can't find a branch in Savannah, but Dick Mao's Emacs fork claims non-blocking Gnus among features. And it unlocks nnimap's process: https://github.com/commercial-emacs/commercial-emacs/blob/6d3ff0428337a734136d00cf2294aa9d3dbcff0e/lisp/gnus/nnimap.el#L592 Maybe someone could test it out.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 19:30:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 15:30:43 2025 Received: from localhost ([127.0.0.1]:49357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuFfP-0000Ue-9c for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:30:43 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:42659) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1uuFfI-0000UI-Tw for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:30:38 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86zfbahvka.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 04 Sep 2025 22:22:29 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN> <ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN> <ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN> <ierjz2ei31b.fsf@HIDDEN> <86zfbahvka.fsf@HIDDEN> Date: Thu, 04 Sep 2025 15:30:30 -0400 Message-ID: <iera53ahv6x.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=1757014230; bh=CieaTAQqhc47bvZXRrlaAJAFQ9SzsdB6iANvkSAcsIQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=kYMHNYJOxw2oLLTPSMNuau46WA1F3dzDu0qZk+AsQtLASeBA7SyCtXa8ouyYExMEg qPG+u+4mc8Q9+y42qimoVU9FHCAh9EV9eSGZyUP0uy5EEuP7wTkWowQCyvBd5KKBtr XNmKS7BnUgiRJzSI83f9udwYFeBP0pK/5NOqGVGKsroE2cNVtgAt2m+4OijnmaNCpa Zp/+MuY5EMiZsndLmbehXecSqbgOf6oSZLKFp2n+4j6ymcZbPimeF1ZIbSfCr3dvcC YPu9yz/MbJmeXkR+Q4CH9l3ipqENZ7VWyd8tKSEhYD96O/5WlGYpuVyR9tbfI58Llt +u+Fd2UUnufFw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN >> Date: Thu, 04 Sep 2025 12:41:04 -0400 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> We should probably just unconditionally do: >> >> pset_thread (p, ps->thread) >> >> here. >> > >> > That's a bit dangerous, since the I/O descriptors of the new process >> > are not yet set, so the call to pset_thread there, in case ps->thread >> > is non-nil, would do a partial job. We could instead move the >> > pset_thread call to later, where set_proc_thread is called, but I >> > preferred to undo what make_process did ASAP. >> >> I'm confused. >> >> - It's just duplicating what make_process did, so I expect it's >> essentially a no-op, just simpler code. >> >> - Why would it be dangerous even if that wasn't the case? We're still >> setting up this process, it's not visible to any Lisp code, so what >> bad event could even happen? > > Having some part of server_accept_connection, even a small part, run > with the new process locked to a thread introduces a window during > which the process is in an incorrect state, and I would like to avoid > that if possible. Admittedly, in this case the window is very small, > but it is still there. Some future changes could actually trip on > that. It's already locked to a thread by make_process.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 19:22:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 15:22:52 2025 Received: from localhost ([127.0.0.1]:49328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuFXn-0008SG-Tg for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:22:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:49384) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uuFXc-0008Qn-TN for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:22:47 -0400 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 1uuFXV-0007xU-D2; Thu, 04 Sep 2025 15:22:33 -0400 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=AtkYKyX/TqSsywJ6qxsMUnVScmGEk4Pv5yx8VvOD3UA=; b=em4i19I3cGJV 1I1LhVqUj4vQtiuf5tQLo8XDy4V2iT4RS8OU+ZvLAxz1Ocv7MP3gyYRLQxXtay/BlFf7UaUx+H/8h mW8RqAG0lTK2y2o6TEsayC+RY93Pc4nNQwHvlJDft6nqlInx99oSoFNArRnqtVRFcQz8mKnlwxjh9 evFEkKLsB1C5Cc0VM2RbcKmhPQ4kqIjZjHZLVldBz1y5scrEA5iW50uitxecjuH6XHYO7zdlCmGaR rN+J9AkDvXIw9zVlGYoj2jShLz0vRSZyJwDZtztp78y3IEyItNTAA8KFPI3ehIZ4ubuNoVC5LyUCZ /xyAtMzB2U/seqpKTTUVUw==; Date: Thu, 04 Sep 2025 22:22:29 +0300 Message-Id: <86zfbahvka.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierjz2ei31b.fsf@HIDDEN> (message from Spencer Baugh on Thu, 04 Sep 2025 12:41:04 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN> <ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN> <ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN> <ierjz2ei31b.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN > Date: Thu, 04 Sep 2025 12:41:04 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> We should probably just unconditionally do: > >> pset_thread (p, ps->thread) > >> here. > > > > That's a bit dangerous, since the I/O descriptors of the new process > > are not yet set, so the call to pset_thread there, in case ps->thread > > is non-nil, would do a partial job. We could instead move the > > pset_thread call to later, where set_proc_thread is called, but I > > preferred to undo what make_process did ASAP. > > I'm confused. > > - It's just duplicating what make_process did, so I expect it's > essentially a no-op, just simpler code. > > - Why would it be dangerous even if that wasn't the case? We're still > setting up this process, it's not visible to any Lisp code, so what > bad event could even happen? Having some part of server_accept_connection, even a small part, run with the new process locked to a thread introduces a window during which the process is in an incorrect state, and I would like to avoid that if possible. Admittedly, in this case the window is very small, but it is still there. Some future changes could actually trip on that. > >> It's not necessary to call set_proc_thread(p, NULL) in the other case > >> since it will just set .thread to NULL, which we're already asserting > >> anyway. > > > > The assertions compile to nothing in a production build. > > Then maybe we should turn this assertion on by default in production > builds, since threads are still encountering problems, and it would help > catch problems. Production builds are not for catching problems, at least not in my book. A production build should try to avoid aborts if possible, because an abort might mean loss of edits. That's why we have eassert to begin with: we use the period of time that code is on the development branch to catch errors and fix them. > Zhengyi says he saw in a debugger this field was set to > non-NULL at this point, which indicates a bug, so it would help tracking > that down. Building with --enable-checking will allow us to do that.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 16:41:21 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 12:41:21 2025
Received: from localhost ([127.0.0.1]:48645 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uuD1T-00008E-T0
for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 12:41:20 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:48379)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1uuD1K-00007g-D5
for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 12:41:12 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
In-Reply-To: <86ikhykem2.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 04 Sep
2025 07:48:05 +0300")
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN>
<ierseh3jwhv.fsf@HIDDEN> <86ikhykem2.fsf@HIDDEN>
Date: Thu, 04 Sep 2025 12:41:04 -0400
Message-ID: <ierjz2ei31b.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=1757004064;
bh=THTco5ZIsEpakAcVVG6oWH2J2evVGre5N19ZItjBALw=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=yJT9oXaSfUeFnprc0auP23TP/R/67OyXwPGrRKZHYbzkChjZhilevV8gBOrJpGN+f
sTGd/AJ6h+4smTwmAcyF5NjnH0Kc5J5yrxGa20hYvfT5pueUMQsOX32oTry6v3GWKD
1/cbheoq6xUtJx4Ijt2WMUo4FLSCweaSPYOITxUald6a+tytxMDfiNNT8rr8AKWrnI
ltfdfEK8lttdCRO0qQlDhCzClVb9Y4I/om5UG+NzWUWWWCDHiSXhEWcVxb7Z5uUKHA
EL5U74Iza5m00T8guOeDhtKFUcylSGInqjfCmEBJVVWJFWANkZvvk+Zbs+mI6RHXrH
bdkF+MNw/4eqA==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
>> Date: Wed, 03 Sep 2025 13:07:08 -0400
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> > + /* make_process calls pset_thread, but if the server process is not
>> > + locked to any thread, we need to undo what make_process did. */
>> > + if (NILP (ps->thread))
>> > + pset_thread (p, Qnil);
>>
>> We should probably just unconditionally do:
>> pset_thread (p, ps->thread)
>> here.
>
> That's a bit dangerous, since the I/O descriptors of the new process
> are not yet set, so the call to pset_thread there, in case ps->thread
> is non-nil, would do a partial job. We could instead move the
> pset_thread call to later, where set_proc_thread is called, but I
> preferred to undo what make_process did ASAP.
I'm confused.
- It's just duplicating what make_process did, so I expect it's
essentially a no-op, just simpler code.
- Why would it be dangerous even if that wasn't the case? We're still
setting up this process, it's not visible to any Lisp code, so what
bad event could even happen?
>>
>> > /* Build new contact information for this setup. */
>> > contact = Fcopy_sequence (ps->childp);
>> > @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel)
>> > add_process_read_fd (s);
>> > if (s > max_desc)
>> > max_desc = s;
>> > + /* If the server process is locked to this thread, lock the client
>> > + process to the same thread, otherwise clear the thread of its I/O
>> > + descriptors. */
>> > + if (NILP (ps->thread))
>> > + {
>> > + eassert (!fd_callback_info[p->infd].thread);
>> > + set_proc_thread (p, NULL);
>>
>> Yes, this is the right assertion. But it should be outside the if/else
>> because it's true even if ps->thread isn't nil.
>
> I don't mind moving it out.
Great.
>> This whole if/else conditional should probably be just:
>>
>> eassert (!fd_callback_info[p->infd].thread);
>> if (!NILP (p->thread))
>> {
>> eassert (XTHREAD (ps->thread) == current_thread);
>> set_proc_thread (p, XTHREAD (p->thread));
>> }
>>
>> It's not necessary to call set_proc_thread(p, NULL) in the other case
>> since it will just set .thread to NULL, which we're already asserting
>> anyway.
>
> The assertions compile to nothing in a production build.
Then maybe we should turn this assertion on by default in production
builds, since threads are still encountering problems, and it would help
catch problems. Zhengyi says he saw in a debugger this field was set to
non-NULL at this point, which indicates a bug, so it would help tracking
that down.
> Also, I don't like the caller to assume too much about what
> set_proc_thread does, it's not future-proof. So I'd prefer to leave
> that call in place.
That's fair. Though, I think the way set_proc_thread works is a bit
confusing, so I'm inclined to refactor it in the near future anyway.
But, the reason I'd like to take out the call is that it will mask
errors created elsewhere by clearing the field.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 05:19:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 01:19:06 2025 Received: from localhost ([127.0.0.1]:44517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uu2NG-0002Yd-3L for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 01:19:06 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56002) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uu2ND-0002Y7-H6 for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 01:19:04 -0400 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 1uu2N6-0008PU-ME; Thu, 04 Sep 2025 01:18:56 -0400 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=ykJYTfbKRn5xgg3C2HcoHarEk0lqv0wBElDyGxogdfI=; b=XmToRYpOpaRq pwuewjQf+W/bxfpECzDczvJrvjhSbYZ+a2s0wIzpIrPmfjYrJhMvPyVwbETvXSxh7hPlSyWJIYazF Pk8TlWw+3wkYDz0Oy5BoO7mvX9sE97oRcj3+0RQ0uNCq+FapI90btLw9FaeADsOrOjjcrR+/kBnLt 6yRQOaM1uCLmZHMh4DF/zLxAvr5tyTaqQcEqFp5E+mh/L+JAI7va9ayEKmNGl58l5hj922mvo/k5U uSQvxTtx86N0dS7t7L4Z9hYwmU6AyUslUNwgkseQ644vXvD9baMRMJGkCUBQWC5dN3/eNUly1rwhV YRBuTpdGPbYlQglQ2MwhLQ==; Date: Thu, 04 Sep 2025 08:18:54 +0300 Message-Id: <86ecsmkd6p.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierplc7jttx.fsf@HIDDEN> (message from Spencer Baugh on Wed, 03 Sep 2025 14:04:42 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <ierplc7jttx.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org > Date: Wed, 03 Sep 2025 14:04:42 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 > > > If you study the code in wait_reading_process_output, you will > > immediately see what kind of godawful mess will that cause with > > reading output from several processes started by several threads. > > > > wait_reading_process_output was written under an implicit assumption > > that there's only one thread that handles all the subprocesses. > > Therefore, it consistently checks all of the I/O descriptors for > > available input from the subprocesses, and consumes that as soon as > > it's available. That cannot possibly work reliably, let alone > > predictably, when several threads are involved. This is so obvious > > from reading the code that I'm astonished I need to even explain it. > > Note that we need to make sure wait_reading_process_output works > reliably in this case for the sake of processes which aren't locked to > threads. So defaulting to locking processes to threads doesn't actually > help with this. Not if we consider unlocked processes a rare and unusual thing to do, in which case programmers that use this are responsible for the dealing with the results. We made such a change in comp.el, but I cannot say I'm too happy with it, and hope we will revisit that later and find a better solution. We do need to make sure nothing disastrous happens in that case, like crashes or EBADF or Emacs hung and unresponsive, but that's just a small part of "works reliably", and is not my primary concern here. My primary concern is that the results of letting processes be unlocked will cause many unexpected and randomly-unpredictable results, which will avert people from using threads. Because who will want to use an infrastructure that makes working Lisp programs unpredictable when run from a non-main thread? > So, to summarize, it sounds like your issue with not locking processes > to threads is: > > Without locking processes to the creating thread, a process's output > can be read by some other thread during the wait, and then our thread > will hang forever if it calls accept-process-output after the wait > ended. Either "hang forever", or fail to work because the expected output is "stolen" by another thread, or run the process filter in the context of another thread (where, for example, things like the current buffer and match-data are different), or some other such unexpected conditions. > This is unfortunately not detailed enough to translate into code. I've > never seen a real-world program which would be vulnerable to this > problem, as described here. I can make up toy programs which meet this > description which would hang, but I'm not sure they're actually what > you're concerned about. Especially because they aren't anything like > real-world programs. I toy program that looks valid and runs in a single-threaded Emacs, but hangs or fails when run from a non-main thread is already a problem. Whether it is interesting for us depends on the program. A toy program which demonstrates an issue that real-world programs will meet is interesting. In any case, it is clear to me, and should be clear to anyone else, that taking a Lisp program written for a single-threaded Emacs and running it from a non-main thread will be made easier if the output from the sub-processes started by that program will be read only by that thread, because that is closer to the assumptions under which the original code was written. > Could you give some more details about the scenario, so I can try to > write a test demonstrating the problem? Or could you point to a > real-world program which is vulnerable to this problem, so I can turn it > into a test? I've never used or debugged a real-world program where these aspects come into play. My experience is almost exclusively with small "toy" programs and test programs, the ones we have in the test suite and also those submitted as part of relevant bug reports. You may wish looking at running the Gnus function that fetches articles from a separate thread (I think someone tried that at some point), and you may wish talking to Michael Albinus, who tried using threads in Tramp (I think he has that on a branch somewhere?).
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 04:48:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 00:48:19 2025
Received: from localhost ([127.0.0.1]:44456 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uu1tS-0000sR-Re
for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 00:48:19 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44550)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uu1tP-0000s7-Tl
for 79367 <at> debbugs.gnu.org; Thu, 04 Sep 2025 00:48:17 -0400
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 1uu1tI-0003OX-Dg; Thu, 04 Sep 2025 00:48:09 -0400
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=d8rhIzvu+c2km9wahldEnf1eYCWVlpsa0VL7nmYJNKQ=; b=dobGe5bJ6WcX
yyQYPqWwO/v4iBZll89N7h+V1akUCXy8zUocL2TP0NqLqWmqpDn0knLR9AmAO/fxYtaqiktrX6ILz
M9evvKJ65M+qh9No3q+rSd8+OoB4crrcfWkXyj62TN+pMT9JOcyyBuSMwoRUi/nSg4ruWHkqw5cXd
uJTi3TIg6OTsMRaHW1Qb4aC1hkBmCsr6I7tP8nGTG1a1Sgk0TS+AZvJmbZoaRME0EzBCPxYROGcPh
rruSLPQS0rQAny/FjU4hCtD6TN6w1ApT2uvx1M5XbSBXcYV6yzlmwrObRynMxEPkU+miZj9KBq8GB
n2gSomEZ/LPDBeWnK/x1rQ==;
Date: Thu, 04 Sep 2025 07:48:05 +0300
Message-Id: <86ikhykem2.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <ierseh3jwhv.fsf@HIDDEN> (message from Spencer Baugh on
Wed, 03 Sep 2025 13:07:08 -0400)
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN>
<ierseh3jwhv.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---)
> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
> Date: Wed, 03 Sep 2025 13:07:08 -0400
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> > + /* make_process calls pset_thread, but if the server process is not
> > + locked to any thread, we need to undo what make_process did. */
> > + if (NILP (ps->thread))
> > + pset_thread (p, Qnil);
>
> We should probably just unconditionally do:
> pset_thread (p, ps->thread)
> here.
That's a bit dangerous, since the I/O descriptors of the new process
are not yet set, so the call to pset_thread there, in case ps->thread
is non-nil, would do a partial job. We could instead move the
pset_thread call to later, where set_proc_thread is called, but I
preferred to undo what make_process did ASAP.
>
> > /* Build new contact information for this setup. */
> > contact = Fcopy_sequence (ps->childp);
> > @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel)
> > add_process_read_fd (s);
> > if (s > max_desc)
> > max_desc = s;
> > + /* If the server process is locked to this thread, lock the client
> > + process to the same thread, otherwise clear the thread of its I/O
> > + descriptors. */
> > + if (NILP (ps->thread))
> > + {
> > + eassert (!fd_callback_info[p->infd].thread);
> > + set_proc_thread (p, NULL);
>
> Yes, this is the right assertion. But it should be outside the if/else
> because it's true even if ps->thread isn't nil.
I don't mind moving it out.
> This whole if/else conditional should probably be just:
>
> eassert (!fd_callback_info[p->infd].thread);
> if (!NILP (p->thread))
> {
> eassert (XTHREAD (ps->thread) == current_thread);
> set_proc_thread (p, XTHREAD (p->thread));
> }
>
> It's not necessary to call set_proc_thread(p, NULL) in the other case
> since it will just set .thread to NULL, which we're already asserting
> anyway.
The assertions compile to nothing in a production build. Also, I
don't like the caller to assume too much about what set_proc_thread
does, it's not future-proof. So I'd prefer to leave that call in
place.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 4 Sep 2025 01:33:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 21:33:49 2025 Received: from localhost ([127.0.0.1]:44015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utyrE-0005ZF-CW for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 21:33:49 -0400 Received: from fout-b5-smtp.messagingengine.com ([202.12.124.148]:59933) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1utyr7-0005Yw-Lr for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 21:33:44 -0400 Received: from phl-compute-11.internal (phl-compute-11.internal [10.202.2.51]) by mailfout.stl.internal (Postfix) with ESMTP id 44BAD1D00221; Wed, 3 Sep 2025 21:33:35 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-11.internal (MEProxy); Wed, 03 Sep 2025 21:33:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756949615; x=1757036015; bh=C6HLUHnPs1egmfCaQZRYj/fc9hwzCA0i1LcjUSrhA0g=; b= d4TBAtVKZy4x1fkXCRwq80B7BbJU20oxmuwx7hnbphnbefY433kNv5zz+U8rDKmP Bo/s180kF32QT4dZxkxQ8vaSgflGZsw2ni8tnMJhQ46Sv0iVsFsmJijIW534MnxO OrSg9i/VfCnFydmeE/GVfYI44qQIZwBJkS0AaKz92+BNhoVcANAvbeCATiP31T88 rBkM3Seu95jRSWgCPfXFPuumfCCYvyz1tkowAL1wdRFaJeFCICt3cPnH6nXcPtAL 4/GTpB5gqa324dIpZFljLCe9ZQrFNh+ITi/ot1GFsv+RubNsUi3M8HaA9aJXTdIW GVw/6O7QT7ky/7FL3omlwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756949615; x= 1757036015; bh=C6HLUHnPs1egmfCaQZRYj/fc9hwzCA0i1LcjUSrhA0g=; b=O 5eTk43uZju6MtWH45HQCOLpMYG6TOsDpgTdTtpLxOfcjFzBtYgaXQZ6dfVhC2qiC 0IRAdOK24BKd3vM6I7cMiHe/Jpsbv5OEU+3vecVNd8kPZuXiPzdy3UCFs7vbb7b6 TdOdV0sLte4h18JRKwc2y//1uoduQW7IB9k84Onjc+B099aRhLwa+X0N82w/7GDj YlBM0lhiR5+enzJ55FABgQHJqHJQvleBJmkkc1lXkjAAg3duj49uLc69lTYI6G6j jce/rOmikYFTU7+LuzEkSfj8MusTQQdyC+PwhiS6tzPRoaJNn08FNg/GO2M5ofyN h+IlGc08N4AcOdxsNm4qA== X-ME-Sender: <xms:buy4aK_waNmoCfXf7ml_X9ucZk2yoWVDlSH38nPXaQxR7xlgMdTDWg> <xme:buy4aFTCKes2kGqPwlc6JbhkH7UZWz5OFINnDWMpEzLyj40Zkmyov2_trW2OIFXnC bRa1SBeONwcmULe0z4> X-ME-Received: <xmr:buy4aMlD73tZXqEczyO0T4PXSjqXWT7tybTeKReL07HbFabMLvfyWZA5mumdEMBfTSbS> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegjeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epffeifedvleeukedtgfelieegudfgveekfeejveejffetffeuueeugefhveeiuddvnecu ffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepughmihhtrhihsehguhhtohhvrdguvghvpdhnsggprhgtphht thhopeegpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdroh hrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghp thhtohepihesfhhuiiihrdhmvgdprhgtphhtthhopeejleefieejseguvggssghughhsrd hgnhhurdhorhhg X-ME-Proxy: <xmx:buy4aFSoUzQrQ-pQvJNoDzA3uYjjH6CqDoB2PqxC71FjLujDY682zw> <xmx:buy4aKNx4MTK9NUJwbMPO8zpVcOYNk7SEAdhvaEUy90nUhzTmHhe-g> <xmx:buy4aOXn1x08mvuKcMBbUFY8bU7EEOKtIUMyhrZGNA6qSlOKJGSKbQ> <xmx:buy4aBdhjieOh0gY2D0ogkh2ZxQrc4Tt1tYTdWq5Vg_h8LCEgkx73A> <xmx:b-y4aKmtZXIVLWdQNnWKBhg4q4Dcb67XPN33NLPSf0Vmm6WfQBlkbb70> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Sep 2025 21:33:33 -0400 (EDT) Message-ID: <6eb705bd-7481-4e77-9f76-b0815d373c5a@HIDDEN> Date: Thu, 4 Sep 2025 04:33:31 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t To: Eli Zaretskii <eliz@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> <868qivlpkp.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <868qivlpkp.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 03/09/2025 14:53, Eli Zaretskii wrote: >>>> I don't want us to spend a lot of time arguing revert-or-no-revert now, >>>> but could you, Eli, try to decide on a full example of a buggy scenario >>>> which is really solved by thread locking being? >>> >>> I already described that in so many words. That is all I can afford. >> >> We need a fuller scenario. If not with code, then a full use case >> described in English. > > I described some of them, and just now posted a list of my messages in > bug#79201 where I did that. That's the best I can afford doing at > this time, sorry. Thanks. Will follow the subthread that sprung from this paragraph. >> I'm pretty sure more of your time is being wasted on answering the >> emails with objections. Regrettably. > > Yes. And I still consider this a worthwhile investment, if as result > we will become on the same page regarding how the relevant code works > and what should be our expectations from it. I hope to get there as well. >> IIUC the existing protection did very little in practice, all of these >> years: it only stopped some thread calling 'accept-process-output' with >> an explicit reference of a process belonging to another thread. > > That's not "very little" at all. And if some Lisp program called > set-process-thread, it would do exactly what is now done by default. Right. But we don't know of any that did. >> Any kind >> of buggy code would have to try hard to obtain that reference in the >> first place - so that would almost never happen anyway. The new >> protections seem a lot more strict. > > Yes, it is stricter. Because that's the intent, as is clear both from > the code and from the documentation, and also because it makes Lisp > programs much easier to reason about. > > I also don't quite see a disaster this change is causing to code which > disregarded the documented restriction. All we had till now is a > single bug report, which clearly indicates that my change was > incomplete, and is easy to fix. I fail to understand the amount of > excitement due to a change that turns out not to be different from > many other changes we make in development. Spencer also previously mentioned breakage in some existing code, there was an example in another thread (not about native compilation). > Here's one recent example: > > https://lists.gnu.org/archive/html/emacs-devel/2025-09/msg00002.html > > This even broke the build, which is clearly a serious regression. And > the solution was that Mattias quickly installed two followup changes; > case closed. Good job, Mattias! I'm good with fixing this bug report the expedient way. >> TBC I think we should continue to support locking, and your current fix >> seems productive in this regard, but whether locking should be by >> default is not obvious to me - and at least two smart devs who worked >> with Emacs Lisp threads say no. That seems like grounds to re-evaluate. >> Even if we reach the current default we'll have documented our >> conclusions better rather than just saying "this is so". > > I'm not saying we cannot revisit the decision to lock processes to > threads. But given that the original design and implementation > clearly tell us that was the intent, I think we should start from what > we have, and only change it if we decide that the current default is > wrong in too many important cases. For now all we have is 2 cases: > one was solved yesterday by unlocking the process, the other is the > one discussed here, which uncovered a flaw in the change I installed, > and should be easy to fix. That's not enough to declare the idea of > locking wrong as the default, let alone bankrupt. Certainly. > For such a > far-reaching conclusion we need much more data points, of both kinds. > My knowledge of this code and my experience, based on 12 years of > developing, maintaining, and fixing bugs in it, is that letting random > threads read output from subprocesses causes many unexpected behaviors > and thus triggers subtle bugs and non-determinism in seemingly valid > Lisp programs. I have an inkling that even in the single-threaded case accept-process-output can behave unpredictably enough that people use it in a certain way (in a loop, with low timeout). Which could smooth over unpredictabilities across multiple threads as well. There are some exceptions to that, though. > You think differently, but please don't dismiss my > opinions on this too quickly, given my familiarity with the code in > this area and the amount of time I spent on it. Just to be clear, I haven't formed an opinion on this myself yet. Just hoping for a more thorough discussion. Sorry if it comes across differently.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 18:04:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 14:04:51 2025 Received: from localhost ([127.0.0.1]:41879 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utrql-0001pU-2z for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 14:04:51 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:57129) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utrqi-0001pG-Fg for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 14:04:49 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86a53blqux.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 03 Sep 2025 14:25:58 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> Date: Wed, 03 Sep 2025 14:04:42 -0400 Message-ID: <ierplc7jttx.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=1756922682; bh=AfwoCdfK0HeKIOIqJfe7ciUvcXHHWB86uRuSyhdodXA=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=OxC4bVdiLsaY2tc97wBmiXiBDf65yYim13q56KKBzwZ33J7Rna14SbiSj2nW1hbmD bxljMkus6GJMTs2jgTpAkxXg9EMB1x3WjMRdjDJyWGJiEgW4XClzKSysQM1fM86v34 hkuF/E7tHf4UBYPqUsGbyqW+AgbWE2Qs+HSSNsCZdsw5WjM4qF92m1wJzgwG93vbgm ZrKX2AFc0bT8gMlSAVg3EX0DNckJ7nbyLzPou6Q8JwOczvY/avRdVorrXodBHJe4wJ CLviRnw8Btr5g2sFrzDXNsj+Rps3mHfw/wX/V7a0XqLIIcaw60AP5ZNifrPA6TfDv6 ILSUmMNfpvyxA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: Dmitry Gutov <dmitry@HIDDEN>, i@HIDDEN, 79367 <at> debbugs.gnu.org >> Date: Tue, 02 Sep 2025 15:33:46 -0400 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > I can code the proposed fix in a few minutes, if there's agreement to >> > what I proposed to do. I'm still uncertain what I proposed is >> > agreed-upon. So let me reiterate that: >> > >> > . if the process on behalf of which we called >> > server_accept_connection was not locked to some thread, undo what >> > make_process did to the new process when it called pset_thread >> > . otherwise, call set_proc_thread to lock the new process to the >> > same thread as the one which caused this call >> >> Whatever you do, please post your change for review rather than just >> pushing it. > > Will do. > >> >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> >> but could you, Eli, try to decide on a full example of a buggy scenario >> >> which is really solved by thread locking being? >> > >> > I already described that in so many words. >> >> Can you send that full description again? Perhaps I can translate it >> from words into code for you. > > Look at my posts as part of discussing bug#79201. For example: OK, attempting to excerpt the parts where you describe what could go wrong when a thread is unlocked: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#88 > Wouldn't we want the thread to be able to read the output > from its process after the wait? Without marking the descriptors with > the thread, that output could have been read by some other thread > during the wait, and then our thread will hang forever if it calls > accept-process-output after the wait ended -- a much more serious > problem, and in a program that has no bug per se. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#94 > > > An output from a process could have been read by a thread other than > > > the one that started the process, thus "starving" the thread that > > > started the process from reading its output. > > > > That has been possible, and common, since threads were originally added. > > And caused strange bugs, whereby a thread that started a process would > hang in accept-process-output because some other thread inadvertently > read the output from that process. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 > If you study the code in wait_reading_process_output, you will > immediately see what kind of godawful mess will that cause with > reading output from several processes started by several threads. > > wait_reading_process_output was written under an implicit assumption > that there's only one thread that handles all the subprocesses. > Therefore, it consistently checks all of the I/O descriptors for > available input from the subprocesses, and consumes that as soon as > it's available. That cannot possibly work reliably, let alone > predictably, when several threads are involved. This is so obvious > from reading the code that I'm astonished I need to even explain it. Note that we need to make sure wait_reading_process_output works reliably in this case for the sake of processes which aren't locked to threads. So defaulting to locking processes to threads doesn't actually help with this. > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#106 > Moreover, IME many weird problems and buggy behavior in Lisp programs > using threads were caused by the wrong thread inadvertently reading > output of a process, which then left the thread that waits for that > process's output stuck waiting forever. If anything, we should make > process locking to its thread stronger, not weaker, if we want > relatively simple threaded programs to work reliably. So, to summarize, it sounds like your issue with not locking processes to threads is: Without locking processes to the creating thread, a process's output can be read by some other thread during the wait, and then our thread will hang forever if it calls accept-process-output after the wait ended. This is unfortunately not detailed enough to translate into code. I've never seen a real-world program which would be vulnerable to this problem, as described here. I can make up toy programs which meet this description which would hang, but I'm not sure they're actually what you're concerned about. Especially because they aren't anything like real-world programs. Could you give some more details about the scenario, so I can try to write a test demonstrating the problem? Or could you point to a real-world program which is vulnerable to this problem, so I can turn it into a test?
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 17:07:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 13:07:17 2025
Received: from localhost ([127.0.0.1]:41392 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utqx3-00053L-2w
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 13:07:17 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33903)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1utqwz-00052d-Dv
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 13:07:14 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
In-Reply-To: <86ldmvjxmg.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 03 Sep
2025 19:42:47 +0300")
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN> <86ldmvjxmg.fsf@HIDDEN>
Date: Wed, 03 Sep 2025 13:07:08 -0400
Message-ID: <ierseh3jwhv.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=1756919228;
bh=DqQrHCBuKkeQ/J/i1Ln383EBPE/pg5jc62Ix657DHOk=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=uWTG0WUPICvFs9bFbuaKfk+mYmJvs8YEpImGxEsA3FIZt+sKG7e1AEp8K+QF7Lrpt
HiSZrkb0WCuZ8ef2y8n9I6FA1DU4rNakGxNt4161BCtAMgIyTIzqmeqy2aUVqqqFmm
C/qCXUuSbRbT0APR5QHpCOzx9XroCWzWkzN0B49+BaE/7dNjd9rpuiPLobQqLomXtA
JvCowQUr6+bDm2NoE4TJbFWS4qvk0DRHbsXkWtlEX9DhUHUOUeYV7PanJUOnSePLv0
flcD1rRnG1zBhMc6onc8aSMhcU18xuWUa/tbN+gWooQ0C7G6or/qo/y540GdgdzCp8
JHznpFpiu/pTw==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Spencer Baugh <sbaugh@HIDDEN>
>> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
>> Date: Wed, 03 Sep 2025 12:03:42 -0400
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> >> >> But I think we need to call set_proc_thread when the server process
>> >> >> is not locked as well. Otherwise the `thread' member of the
>> >> >> fd_callback_info may still be a dangling pointer.
>> >> >
>> >> > Oh, you mean the below? I agree, it is safer.
>> >>
>> >> We should not do that - if the thread member of fd_callback_info is a
>> >> dangling pointer, that indicates there's a bug elsewhere.
>> >
>> > So how about adding an assertion before we clear it?
>>
>> Sure. fd_callback_info.thread specifically should always be NULL at the
>> time we're using the fd_callback_info slot for some new fd, so we should
>> assert that.
>
> So, this:
>
> diff --git a/src/process.c b/src/process.c
> index d6efac5..8f5be5e 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
> fcntl (s, F_SETFL, O_NONBLOCK);
>
> p = XPROCESS (proc);
> + /* make_process calls pset_thread, but if the server process is not
> + locked to any thread, we need to undo what make_process did. */
> + if (NILP (ps->thread))
> + pset_thread (p, Qnil);
We should probably just unconditionally do:
pset_thread (p, ps->thread)
here.
> /* Build new contact information for this setup. */
> contact = Fcopy_sequence (ps->childp);
> @@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel)
> add_process_read_fd (s);
> if (s > max_desc)
> max_desc = s;
> + /* If the server process is locked to this thread, lock the client
> + process to the same thread, otherwise clear the thread of its I/O
> + descriptors. */
> + if (NILP (ps->thread))
> + {
> + eassert (!fd_callback_info[p->infd].thread);
> + set_proc_thread (p, NULL);
Yes, this is the right assertion. But it should be outside the if/else
because it's true even if ps->thread isn't nil.
This whole if/else conditional should probably be just:
eassert (!fd_callback_info[p->infd].thread);
if (!NILP (p->thread))
{
eassert (XTHREAD (ps->thread) == current_thread);
set_proc_thread (p, XTHREAD (p->thread));
}
It's not necessary to call set_proc_thread(p, NULL) in the other case
since it will just set .thread to NULL, which we're already asserting
anyway.
> + }
> + else
> + {
> + eassert (XTHREAD (ps->thread) == current_thread);
> + set_proc_thread (p, XTHREAD (ps->thread));
> + }
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 16:43:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 12:43:23 2025
Received: from localhost ([127.0.0.1]:41266 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utqZu-0003dB-Jl
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:43:23 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:52186)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utqZr-0003cp-HH
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:43:20 -0400
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 1utqZl-0003Vb-4D; Wed, 03 Sep 2025 12:43:13 -0400
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=CpwLG0ZNoIHPZ6EmpoVmQxFIBBomggEp23dfvCbN0+I=; b=sYXb9dKQfDai
blz79hS8AX/Ua1KQUcKhpawoDVc3zsq+sQC/2QRDlIgawYg6ifELv4bMCYQmRGAnYlRe/nAKCSLwE
xhHOdNBx5kYcVzYy1PQ/geiX+rZ0/7F2zGqrWnAdMspKYze0ENMUpZEP3iEoao9R8e7YVBRQ6Ssr1
8acqp+OPp1KAYkmZVW3wup5I6WqYfikkpkKGHb0Fxcwd+3yza7Tpx3mpj9s5uzMhE8VCmUwN9LwAD
WzguVa0RRf5swLkMmxRYxnW538X8V0hhN38sI8ftnaf28QFAb5aQUsbs407Dcx1QNYa3E/4IwSOpb
YujWvNOVEm3cAgASThI5Rg==;
Date: Wed, 03 Sep 2025 19:42:47 +0300
Message-Id: <86ldmvjxmg.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Spencer Baugh <sbaugh@HIDDEN>
In-Reply-To: <ier3493le01.fsf@HIDDEN> (message from Spencer Baugh on
Wed, 03 Sep 2025 12:03:42 -0400)
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
<ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN>
<ier3493le01.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---)
> From: Spencer Baugh <sbaugh@HIDDEN>
> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN
> Date: Wed, 03 Sep 2025 12:03:42 -0400
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> >> >> But I think we need to call set_proc_thread when the server process
> >> >> is not locked as well. Otherwise the `thread' member of the
> >> >> fd_callback_info may still be a dangling pointer.
> >> >
> >> > Oh, you mean the below? I agree, it is safer.
> >>
> >> We should not do that - if the thread member of fd_callback_info is a
> >> dangling pointer, that indicates there's a bug elsewhere.
> >
> > So how about adding an assertion before we clear it?
>
> Sure. fd_callback_info.thread specifically should always be NULL at the
> time we're using the fd_callback_info slot for some new fd, so we should
> assert that.
So, this:
diff --git a/src/process.c b/src/process.c
index d6efac5..8f5be5e 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
fcntl (s, F_SETFL, O_NONBLOCK);
p = XPROCESS (proc);
+ /* make_process calls pset_thread, but if the server process is not
+ locked to any thread, we need to undo what make_process did. */
+ if (NILP (ps->thread))
+ pset_thread (p, Qnil);
/* Build new contact information for this setup. */
contact = Fcopy_sequence (ps->childp);
@@ -5117,6 +5121,19 @@ server_accept_connection (Lisp_Object server, int channel)
add_process_read_fd (s);
if (s > max_desc)
max_desc = s;
+ /* If the server process is locked to this thread, lock the client
+ process to the same thread, otherwise clear the thread of its I/O
+ descriptors. */
+ if (NILP (ps->thread))
+ {
+ eassert (!fd_callback_info[p->infd].thread);
+ set_proc_thread (p, NULL);
+ }
+ else
+ {
+ eassert (XTHREAD (ps->thread) == current_thread);
+ set_proc_thread (p, XTHREAD (ps->thread));
+ }
/* Setup coding system for new process based on server process.
This seems to be the proper thing to do, as the coding system
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 16:03:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 12:03:52 2025 Received: from localhost ([127.0.0.1]:41168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utpxf-0001jQ-Uw for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:03:52 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:39477) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utpxc-0001j8-Ja for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:03:50 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86o6rrk1fy.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 03 Sep 2025 18:20:17 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> <86o6rrk1fy.fsf@HIDDEN> Date: Wed, 03 Sep 2025 12:03:42 -0400 Message-ID: <ier3493le01.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=1756915422; bh=WL8717ylL4aoUyBzOClfaaiASKxjJygvc1iuiNdBDhI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=MfL+T+YWpXeL+aIDAiyoPPF80jJRqon3DhmVqaNt4eYQm1zOroa1cKtXXliXG0Ii6 rS1xHBO0O5oeHH38aLYxHEsTT9XkdqTHKMeXKcwmOyGnyhQYLGRiiEHQv8FkCrFe8s h6fTtVu1nzWGEGxliwIRQ7alGyIygGs6il4kXSUWw92aGxiC55/pmOE2YfdlPtGr1h cr0yuiaDZquntUGo69nsocHkw4wekVh/pLVkMcIjN0RbZQ1rarJnuobeZnjnz4+Xog BN3LSeBkiZomCefP9WY5kUXsyulFuMnJSP16hkCpbjC11gTuHL9uKSZiDsaW9Dsl4I Fe1btlgd1h+gA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: Zhengyi Fu <i@HIDDEN>, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN >> Date: Wed, 03 Sep 2025 11:00:19 -0400 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> From: Zhengyi Fu <i@HIDDEN> >> >> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org >> >> Date: Wed, 03 Sep 2025 22:42:26 +0800 >> >> >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> >> > Zhengyi Fu, can you please apply it to the current master, and see if >> >> > it solves the original problem? >> >> >> >> It does resolve my original problem. >> > >> > Thanks for testing. >> > >> >> But I think we need to call set_proc_thread when the server process >> >> is not locked as well. Otherwise the `thread' member of the >> >> fd_callback_info may still be a dangling pointer. >> > >> > Oh, you mean the below? I agree, it is safer. >> >> We should not do that - if the thread member of fd_callback_info is a >> dangling pointer, that indicates there's a bug elsewhere. > > So how about adding an assertion before we clear it? Sure. fd_callback_info.thread specifically should always be NULL at the time we're using the fd_callback_info slot for some new fd, so we should assert that.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 15:20:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 11:20:32 2025 Received: from localhost ([127.0.0.1]:41002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utpHj-0007p9-Kv for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 11:20:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57318) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utpHg-0007oo-Dq for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 11:20:29 -0400 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 1utpHY-0003Oc-Q7; Wed, 03 Sep 2025 11:20:20 -0400 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=+hdFGGGzeJZMAxLwmCEksVNho1UyC5W7MDHNDk8w8VA=; b=UlCnV0N7nBto uXs5/6tYwNp6IPqIXWFZ/Tb46U5Ob+27BcT+LC3jvBtskrV/akjGZ0n8O15oVyiPK0jwMyAEDh8D+ wxE1rDCNa2SB5hwWWkiodwgBMYXINJlcLPYTWsEcx2YFzoJacFgE0PfZy0hpX5gfavkThi05DxwzV RXs/Mjd/8QqNPSIHU/3xjQcESPtweFhIWz9BG2H5xd67UMviPU0S6npoPuZ+PRLOBrU8m0/snnQd6 YXJ4/Ra9Y+xlcEc3e1FAAQmVxen512clChToCDIOfXFp2llUBkhkupvetYIEYqzs3xr27g/q8mxOK YiYTvLL+MWpQSMTVW6C+Hg==; Date: Wed, 03 Sep 2025 18:20:17 +0300 Message-Id: <86o6rrk1fy.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier5xdzlgxo.fsf@HIDDEN> (message from Spencer Baugh on Wed, 03 Sep 2025 11:00:19 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> <ier5xdzlgxo.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: Zhengyi Fu <i@HIDDEN>, 79367 <at> debbugs.gnu.org, dmitry@HIDDEN > Date: Wed, 03 Sep 2025 11:00:19 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> From: Zhengyi Fu <i@HIDDEN> > >> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org > >> Date: Wed, 03 Sep 2025 22:42:26 +0800 > >> > >> Eli Zaretskii <eliz@HIDDEN> writes: > >> > >> > Zhengyi Fu, can you please apply it to the current master, and see if > >> > it solves the original problem? > >> > >> It does resolve my original problem. > > > > Thanks for testing. > > > >> But I think we need to call set_proc_thread when the server process > >> is not locked as well. Otherwise the `thread' member of the > >> fd_callback_info may still be a dangling pointer. > > > > Oh, you mean the below? I agree, it is safer. > > We should not do that - if the thread member of fd_callback_info is a > dangling pointer, that indicates there's a bug elsewhere. So how about adding an assertion before we clear it?
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 15:00:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 11:00:28 2025 Received: from localhost ([127.0.0.1]:40870 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utoyJ-0006dM-US for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 11:00:28 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:47967) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utoyH-0006cx-5Z for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 11:00:25 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86plc7k2oy.fsf@HIDDEN> (Eli Zaretskii's message of "Wed, 03 Sep 2025 17:53:17 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> <86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN> Date: Wed, 03 Sep 2025 11:00:19 -0400 Message-ID: <ier5xdzlgxo.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=1756911619; bh=jJIGO7fPF+KAZUlIKyCLwQ19WvI2m1HaLdTPSMH0sEM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=XlYveYEPFIdFDA9TB9Zx5OelwqEljEA+2rpBklAq2y9ygzQJoJs3fGJRF4R2lNOFg MFkcTnehri0AnjxkbPMak7V+kC+YV0WqoaXsPS1C1wr0IEKKFIJ/FgzdGId9zxhDKu gNnEDQHH6XhQoULD4jDJ5im/V4J1ne/DSD0l7XIr6u4bWJo+/pPNOJ7yoBt9uXkISH 7CQPb1kx4xzYA85LExnMq9eM/r5R04jF9tWR/iGr2I9okHC0bUdYAg3qS5dS4aQet1 QGBkR61DtUp0rMEn/T/PeU5wPKYpr1pCaPNGdAsjeYT414U2TEvA0G0EYhr3q904Xa 1Ewx350tTbJ/A== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: Zhengyi Fu <i@HIDDEN>, 79367 <at> debbugs.gnu.org, 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 (---) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Zhengyi Fu <i@HIDDEN> >> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org >> Date: Wed, 03 Sep 2025 22:42:26 +0800 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > Zhengyi Fu, can you please apply it to the current master, and see if >> > it solves the original problem? >> >> It does resolve my original problem. > > Thanks for testing. > >> But I think we need to call set_proc_thread when the server process >> is not locked as well. Otherwise the `thread' member of the >> fd_callback_info may still be a dangling pointer. > > Oh, you mean the below? I agree, it is safer. We should not do that - if the thread member of fd_callback_info is a dangling pointer, that indicates there's a bug elsewhere.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:58:05 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 10:58:05 2025
Received: from localhost ([127.0.0.1]:40861 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utow1-0006Qr-0K
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:58:05 -0400
Received: from relay3-d.mail.gandi.net ([217.70.183.195]:48439)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <i@HIDDEN>) id 1utovy-0006Q7-Ap
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:58:03 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 8E7671F737;
Wed, 3 Sep 2025 14:57:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1;
t=1756911475;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=uC+LbQZQFwyudstsiipzsokRDrgyRrN4/UlNyVB8yCw=;
b=Z6NVVPck2HUDzsOWxtknM1/Wgs/MjTQ7oMAYbkPoWzbZ3Ug+5+xdLWHsAU1OdNI4msFBbo
rAhxUkofbTU5NmBJ2irLdwqcMiZT6F9viDH1BvshoiUjEAR/yabMia2wPp+77ZdW6lTWBt
5YF3pO/lNf1n/94/RaDIFDQYyKxYElEottrGeJeqWINf/oxDRfj86cymVp3S7QJtQL3EDL
OzDREKPWwRaOxNZt/3uA8Rx7VUv28dFiRw733Csnd3dU48roU1fP1YnDBlmXQWMCQCYaqM
+OCfKibytZqXZfJhylalndgEtLFTe+6z5PFZxjBdJfbQz//Lb+W1YnIibNOX2Q==
From: Zhengyi Fu <i@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
In-Reply-To: <86plc7k2oy.fsf@HIDDEN>
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
<87ecsny4vh.fsf@HIDDEN> <86plc7k2oy.fsf@HIDDEN>
Date: Wed, 03 Sep 2025 22:57:50 +0800
Message-ID: <877byfy45t.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefgeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh
X-GND-Sasl: id@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 79367
Cc: sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org, 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.7 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Zhengyi Fu <i@HIDDEN>
>> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org
>> Date: Wed, 03 Sep 2025 22:42:26 +0800
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> > Zhengyi Fu, can you please apply it to the current master, and see if
>> > it solves the original problem?
>>
>> It does resolve my original problem.
>
> Thanks for testing.
>
>> But I think we need to call set_proc_thread when the server process
>> is not locked as well. Otherwise the `thread' member of the
>> fd_callback_info may still be a dangling pointer.
>
> Oh, you mean the below? I agree, it is safer.
>
> diff --git a/src/process.c b/src/process.c
> index d6efac5..2cfff61 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
> fcntl (s, F_SETFL, O_NONBLOCK);
>
> p = XPROCESS (proc);
> + /* make_process calls pset_thread, but if the server process is not
> + locked to any thread, we need to undo what make_process did. */
> + if (NILP (ps->thread))
> + pset_thread (p, Qnil);
>
> /* Build new contact information for this setup. */
> contact = Fcopy_sequence (ps->childp);
> @@ -5117,6 +5121,16 @@ server_accept_connection (Lisp_Object server, int channel)
> add_process_read_fd (s);
> if (s > max_desc)
> max_desc = s;
> + /* If the server process is locked to this thread, lock the client
> + process to the same thread, otherwise clear the thread of its I/O
> + descriptors. */
> + if (NILP (ps->thread))
> + set_proc_thread (p, NULL);
> + else
> + {
> + eassert (XTHREAD (ps->thread) == current_thread);
> + set_proc_thread (p, XTHREAD (ps->thread));
> + }
>
> /* Setup coding system for new process based on server process.
> This seems to be the proper thing to do, as the coding system
Yes.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:53:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 10:53:30 2025
Received: from localhost ([127.0.0.1]:40839 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utora-0006BY-1A
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:53:30 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47968)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utorX-0006BK-Dm
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:53:28 -0400
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 1utorQ-00086a-Vh; Wed, 03 Sep 2025 10:53:20 -0400
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=MrISA5Q9ScbgQmxntFvRJyCRIiUmXAcY6QkOgkhhs+w=; b=pjljptO3Mqg3
lQTUO9y9I4xGwIC4CpcO1g5XbOQ39kgik2mzHZNuRTHjqnghPu631cYoUz/urSakd5JbZX80bXaEC
cuj0mpvcKOEE/JNG0D68Ia0bNcl6R9bbj2f5p2gE0Pz8WlABktE9fy+rdSdjbGR7hmGzd6OavEics
BZWs2mTgNgQxaQbM/Mco2Y2YR0yOig7UWRytC8/TWdl7/hJVo4AU9+aApBBxxjR450ljIJBWtIlXF
8Cv0msPwnuSac0HI3gifDZSSYuDZzh1JOu9qGxcqWnMW1LQ5acwTLgeW1lpBxCtTNHGClnCWi64ds
Wr83uTyvkLPuR5LnZ14fdw==;
Date: Wed, 03 Sep 2025 17:53:17 +0300
Message-Id: <86plc7k2oy.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Zhengyi Fu <i@HIDDEN>
In-Reply-To: <87ecsny4vh.fsf@HIDDEN> (message from Zhengyi Fu on Wed, 03 Sep
2025 22:42:26 +0800)
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN> <87ecsny4vh.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org, 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 (---)
> From: Zhengyi Fu <i@HIDDEN>
> Cc: sbaugh@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org
> Date: Wed, 03 Sep 2025 22:42:26 +0800
>
> Eli Zaretskii <eliz@HIDDEN> writes:
>
> > Zhengyi Fu, can you please apply it to the current master, and see if
> > it solves the original problem?
>
> It does resolve my original problem.
Thanks for testing.
> But I think we need to call set_proc_thread when the server process
> is not locked as well. Otherwise the `thread' member of the
> fd_callback_info may still be a dangling pointer.
Oh, you mean the below? I agree, it is safer.
diff --git a/src/process.c b/src/process.c
index d6efac5..2cfff61 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
fcntl (s, F_SETFL, O_NONBLOCK);
p = XPROCESS (proc);
+ /* make_process calls pset_thread, but if the server process is not
+ locked to any thread, we need to undo what make_process did. */
+ if (NILP (ps->thread))
+ pset_thread (p, Qnil);
/* Build new contact information for this setup. */
contact = Fcopy_sequence (ps->childp);
@@ -5117,6 +5121,16 @@ server_accept_connection (Lisp_Object server, int channel)
add_process_read_fd (s);
if (s > max_desc)
max_desc = s;
+ /* If the server process is locked to this thread, lock the client
+ process to the same thread, otherwise clear the thread of its I/O
+ descriptors. */
+ if (NILP (ps->thread))
+ set_proc_thread (p, NULL);
+ else
+ {
+ eassert (XTHREAD (ps->thread) == current_thread);
+ set_proc_thread (p, XTHREAD (ps->thread));
+ }
/* Setup coding system for new process based on server process.
This seems to be the proper thing to do, as the coding system
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:42:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 10:42:43 2025
Received: from localhost ([127.0.0.1]:40753 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utoh7-0005bJ-Pv
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:42:42 -0400
Received: from relay5-d.mail.gandi.net ([217.70.183.197]:60649)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <i@HIDDEN>) id 1utoh3-0005ax-OO
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:42:39 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 40D9A43A1E;
Wed, 3 Sep 2025 14:42:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1;
t=1756910551;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=08dzd6TZlzQoQj4/FUqZXUKSsjnuCu4A/fsKlm/WM6g=;
b=QdpB+DaI/cMt9IA61eeE7KuoC4BxzLRaTIVjWboWHvq2DygcevZJPaVfgW7ZN8Rt7vkVxb
30jqPgruikLiKQDxz4WFoPO0nwg72ZrKvbEqyOFqeEcYNxfUK0y8rCPBadJO2wtFW1nmOZ
so82VaS4MMcRWWtZpc8r0iXx+yP4FTgPT/rAMqviJPrdzjPS4HWjxinSO+b4L3tfPJEy95
ObWMKKTCR7jLBWKdZDqkHHh+ra+/wnOfzV1RwyeN2G08ka2V/bU6i9sT88ftyurk/og3oA
zJ31TF493v3UJL4NSKLKiSBuONpMsK5JltaZUuHC1hjDwYW4SF8hzE+6HLMrzQ==
From: Zhengyi Fu <i@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
In-Reply-To: <86seh3k4ix.fsf@HIDDEN>
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN> <86seh3k4ix.fsf@HIDDEN>
Date: Wed, 03 Sep 2025 22:42:26 +0800
Message-ID: <87ecsny4vh.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-GND-State: clean
X-GND-Score: -100
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefgeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfgfgggtsehttdertddtredtnecuhfhrohhmpegkhhgvnhhghihiucfhuhcuoehisehfuhiihidrmhgvqeenucggtffrrghtthgvrhhnpeetvdeuveffjedugfdtjeeugfejjeegtdekteefffdtgefgffetffeiuefhtdegfeenucfkphepgeehrdekrddukeeirddutddvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepgeehrdekrddukeeirddutddvpdhhvghloheptggrlhhlihhophgvpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepgedprhgtphhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhgpdhrtghpthhtohepughmihhtrhihsehguhhtohhvrdguvghvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrgh
X-GND-Sasl: id@HIDDEN
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 79367
Cc: sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org, 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.7 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org
>> Date: Wed, 03 Sep 2025 14:25:58 +0300
>> From: Eli Zaretskii <eliz@HIDDEN>
>>
>> > > . if the process on behalf of which we called
>> > > server_accept_connection was not locked to some thread, undo what
>> > > make_process did to the new process when it called pset_thread
>> > > . otherwise, call set_proc_thread to lock the new process to the
>> > > same thread as the one which caused this call
>> >
>> > Whatever you do, please post your change for review rather than just
>> > pushing it.
>>
>> Will do.
>
> The proposed patch is below.
>
> Zhengyi Fu, can you please apply it to the current master, and see if
> it solves the original problem?
It does resolve my original problem. But I think we need to call
set_proc_thread when the server process is not locked as well.
Otherwise the `thread' member of the fd_callback_info may still be a
dangling pointer.
> diff --git a/src/process.c b/src/process.c
> index d6efac5..0c41ec6 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
> fcntl (s, F_SETFL, O_NONBLOCK);
>
> p = XPROCESS (proc);
> + /* make_process calls pset_thread, but if the server process is not
> + locked to any thread, we need to undo what make_process did. */
> + if (NILP (ps->thread))
> + pset_thread (p, Qnil);
>
> /* Build new contact information for this setup. */
> contact = Fcopy_sequence (ps->childp);
> @@ -5117,6 +5121,13 @@ server_accept_connection (Lisp_Object server, int channel)
> add_process_read_fd (s);
> if (s > max_desc)
> max_desc = s;
> + /* If the server process is locked to this thread, lock the client
> + process to the same thread. */
> + if (!NILP (ps->thread))
> + {
> + eassert (XTHREAD (ps->thread) == current_thread);
> + set_proc_thread (p, XTHREAD (ps->thread));
> + }
>
> /* Setup coding system for new process based on server process.
> This seems to be the proper thing to do, as the coding system
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 14:13:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 10:13:58 2025
Received: from localhost ([127.0.0.1]:40691 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utoFJ-0004E0-V8
for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:13:58 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:39110)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utoFE-0004De-PC
for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 10:13:55 -0400
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 1utoF7-00023J-Rw; Wed, 03 Sep 2025 10:13:45 -0400
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=z4RQinoFGwTUfFAsx9g76euurO30UhRSOZtcSvIp/CM=; b=UW4VltxmV4KB
DsUyeHaZWn3/APzHYThGkTZsz+vJnnk2NBKVtaBFANO2aPDu6HqPwD5d9yLT6uGvZeWC3VHXO81Xj
9uiqHxzx3HH0MfNkLQLXuuh50DqgJwFlARGZOoDaOv6NZWEeghRUvhfHMO+VXzS8XVeZ4P6x3m37A
hZYbLGBKwNd9QI0kIIxl7PISSnLXNmJvmntDH9FrxFtLZV1lstWlibpujjEXfBfjlSHrzi3snldQy
zBy/ICnLJD/T35BWqpgkDJnZhBxI+vbJWJNgoVsQbgDgka0k5vShxr3PSAP4o/bC1Q9wyTly95Tcg
8OqLMwzTSpxrh53JKBmwTQ==;
Date: Wed, 03 Sep 2025 17:13:42 +0300
Message-Id: <86seh3k4ix.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: sbaugh@HIDDEN, i@HIDDEN, dmitry@HIDDEN
In-Reply-To: <86a53blqux.fsf@HIDDEN> (message from Eli Zaretskii on Wed, 03
Sep 2025 14:25:58 +0300)
Subject: Re: bug#79367: 31.0.50;
magit-commit sometimes doesn't work if diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
<86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN>
<86a53blqux.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: 79367 <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: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org
> Date: Wed, 03 Sep 2025 14:25:58 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
>
> > > . if the process on behalf of which we called
> > > server_accept_connection was not locked to some thread, undo what
> > > make_process did to the new process when it called pset_thread
> > > . otherwise, call set_proc_thread to lock the new process to the
> > > same thread as the one which caused this call
> >
> > Whatever you do, please post your change for review rather than just
> > pushing it.
>
> Will do.
The proposed patch is below.
Zhengyi Fu, can you please apply it to the current master, and see if
it solves the original problem?
diff --git a/src/process.c b/src/process.c
index d6efac5..0c41ec6 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5078,6 +5078,10 @@ server_accept_connection (Lisp_Object server, int channel)
fcntl (s, F_SETFL, O_NONBLOCK);
p = XPROCESS (proc);
+ /* make_process calls pset_thread, but if the server process is not
+ locked to any thread, we need to undo what make_process did. */
+ if (NILP (ps->thread))
+ pset_thread (p, Qnil);
/* Build new contact information for this setup. */
contact = Fcopy_sequence (ps->childp);
@@ -5117,6 +5121,13 @@ server_accept_connection (Lisp_Object server, int channel)
add_process_read_fd (s);
if (s > max_desc)
max_desc = s;
+ /* If the server process is locked to this thread, lock the client
+ process to the same thread. */
+ if (!NILP (ps->thread))
+ {
+ eassert (XTHREAD (ps->thread) == current_thread);
+ set_proc_thread (p, XTHREAD (ps->thread));
+ }
/* Setup coding system for new process based on server process.
This seems to be the proper thing to do, as the coding system
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 13:15:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 09:15:59 2025 Received: from localhost ([127.0.0.1]:39375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utnLC-0000wB-RD for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 09:15:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46892) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utnL8-0000vp-FW for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 09:15:57 -0400 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 1utnL1-0003oA-GE; Wed, 03 Sep 2025 09:15:48 -0400 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=1RJVuPTwhBm5r2ArNrqK3jDHMsME0Oc/rVxaT/9+Dcs=; b=hg8/jC3wyBhu mGHcEq+YlEi7udHt7BN0shbG2dr8E8/TOtlQ0gxNJmYkpxw5zGmqOjaWK0tLqvH4EPVQFwkON4mYU sIBbZwP+r5Wum8A7gzv64LfcHHcljlFYshuOul4lbZigQb9hiifQti2TsQ819wM9qxphNAwoT2zw5 39nf8fAMDTUer01JgkJyBu567af04oJp0/S2g9cf0v8niNLzMiHhKvYODznyvGKDTfI2waq2btxqw 08NWlo4komXJ73+lZ1F80p74p/XjnzKN1ZyL8UeTg4LEcLYVYqHPUQYEPGrWa0QVnI2lcSttcwTay pFaH+cPDxAXToqjYjiqUng==; Date: Wed, 03 Sep 2025 16:15:42 +0300 Message-Id: <86v7lzk77l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <bf81c4be-e15a-4c7f-ae6e-41ef8bbed25d@HIDDEN> (message from Dmitry Gutov on Wed, 3 Sep 2025 15:17:42 +0300) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> <217ebef0-4b97-47a3-8118-ed1e8c176852@HIDDEN> <867byflpeu.fsf@HIDDEN> <bf81c4be-e15a-4c7f-ae6e-41ef8bbed25d@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <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 (---) > Date: Wed, 3 Sep 2025 15:17:42 +0300 > Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org > From: Dmitry Gutov <dmitry@HIDDEN> > > On 03/09/2025 14:57, Eli Zaretskii wrote: > >> Maybe to start something, do we expect some Comint functionality to be > >> broken when background threads exist and perhaps call > >> 'accept-process-output' with nil, in a loop? > >> > >> Such as comint-redirect-results-list-from-process or comint-proc-query, > >> for example. > > If the process is locked to the thread which runs > > comint-redirect-results-list-from-process, I wouldn't expect problems > > there. But it would be good for someone to look into this, sure. > > Right, I meant the unlocked configuration (this could be an evidence of > it being bad default). I'm not familiar with the expectations of this function. Is it expected to wait in a loop until PROCESS exits, and process the output only then? If yes, the only question is what happens when PROCESS exits while another thread has the global lock. This is related to a problem discussed in bug#79334, so maybe we should revisit this when that bug is deemed solved.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 12:17:56 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 08:17:56 2025 Received: from localhost ([127.0.0.1]:39107 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utmR1-0006Ee-FU for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 08:17:55 -0400 Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:59259) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1utmQy-0006EQ-7d for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 08:17:53 -0400 Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfhigh.stl.internal (Postfix) with ESMTP id B26AD7A02C5; Wed, 3 Sep 2025 08:17:46 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-05.internal (MEProxy); Wed, 03 Sep 2025 08:17:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1756901866; x=1756988266; bh=R5p8T0p+6+iKgeDMN/TImPDQupo6JJk61Xu420K2M44=; b= LUAQ3iBvlHRSzdE2nuBWeADMvA3wSEvY8j60zklDu+s3CX3GXEoeAGOUFO+PwD9Y dUPnBzL9qM/s5meNqepeqzbZ7JAJ6t8auRpq0eR1umHcHc1LYT4AYxfYLRmdUB9A LqYrzSy9SQjSvhquLE5ynFkMVnWvnHv9iDudVYcrUuggDM+LWzov2VmKokJnZBIX ELmoCnhblPYFICuIRGPY0h4TbLbhEcYv80dMA6ERLgQmVpTlWJUlqu75OGxDt4i7 dlAi9r4YkBuDoXyly9HgLwV4kx0g4nl1svHBPXFukpTKoURgjecxZ1AWNhB//+AH T6ZgDo4W77OAMxadcM277A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756901866; x= 1756988266; bh=R5p8T0p+6+iKgeDMN/TImPDQupo6JJk61Xu420K2M44=; b=G WpEOYuXwoK7CzMlif9FjIwQ92r4cle98rm+JmSeQaIQCALbzXLN2mMtOH57hVljk P5HxKi2fUYNbgbnKPKelQOQQNdo/nzcs26gmJfASJ8LoVgrcHlMIgbITITmlbVGR 6gSeaJ4Ggh4wTqY4e5ZXlIBmCkULdPQ/MujH5K1CV4VUSnc1VRdsyR0cpk1cl2LB 514Xv1vvQIj4K9xG6J3VKgvBGvWZoYcaWROyYQt3Q4laQHqQPaga8Kt5tQl6gnHg SpI+9jMSYPrfTR1ZKjmOSzTIITdVBoJqsWj/7qPx7wFnNbHMYJSzDIXBXv2V3RGg AFhOAEGWXShTgtI4mIv2Q== X-ME-Sender: <xms:6TG4aDh1crxDrrcipnRuoyAeLxidtCo7P8eA6EiOamB--X8CxtxqVw> <xme:6TG4aKlGlh_0MgOZSF8r9T9hQuRZdNQDm2EPhzzdDb6UYPBQEarqqrrFvMfOIdTgR FMgyTXiWhjHLG06_5w> X-ME-Received: <xmr:6TG4aPr5YwEnucbtKV9RB-ldobhK9hvG0XNV7-2C5Uo2InZ9fSh1f0hFpGfip5hc6jAt> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdefuddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeehnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihi drmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: <xmx:6TG4aDFB4VVNWe-P7IRzZ9K_L57drb_DLHM_QgDtPx_M7x0bcMxiDw> <xmx:6TG4aLwVPdfO_AWDXxC9Rv7uJb0OcLlYPzipMkuNvWiEHCRNmQXuLA> <xmx:6TG4aIo8xB8f2_NDRMqxVlFS68GEgs_iu7l6NcHXShb0PxXzd6WGMg> <xmx:6TG4aFipVmsBN3CyuRDaVSHE_KfPO0EwcwG-nQPkcRic9GahrE1rXg> <xmx:6jG4aPrREO7OrNTAkCevjWrrcH_nHXfJa50tIwfjvb22qfU7RIZiTYPB> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 3 Sep 2025 08:17:44 -0400 (EDT) Message-ID: <bf81c4be-e15a-4c7f-ae6e-41ef8bbed25d@HIDDEN> Date: Wed, 3 Sep 2025 15:17:42 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t To: Eli Zaretskii <eliz@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> <217ebef0-4b97-47a3-8118-ed1e8c176852@HIDDEN> <867byflpeu.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <867byflpeu.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 03/09/2025 14:57, Eli Zaretskii wrote: >> Maybe to start something, do we expect some Comint functionality to be >> broken when background threads exist and perhaps call >> 'accept-process-output' with nil, in a loop? >> >> Such as comint-redirect-results-list-from-process or comint-proc-query, >> for example. > If the process is locked to the thread which runs > comint-redirect-results-list-from-process, I wouldn't expect problems > there. But it would be good for someone to look into this, sure. Right, I meant the unlocked configuration (this could be an evidence of it being bad default).
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:57:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 07:57:26 2025 Received: from localhost ([127.0.0.1]:39065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utm7C-0005Iu-7K for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:57:26 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47098) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utm78-0005Ic-Ij for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:57:23 -0400 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 1utm72-0003JE-ED; Wed, 03 Sep 2025 07:57:16 -0400 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=q8mgufMl0pBxTX8FJmqbVs3qaXSpSwhjlQhC1ezVEyU=; b=Pe80oKie3+QT MtQSrXlsMGBxDQjh/rPREjYaP1JnIPlCnl1NBRuKxjJTWrCAQ8I9VrS2ZXWfffdVUvCo+Dzu25qzh jjIT/0m9waCF9YcAtJAHxfqxqBboI2J4nwpiHYxXJOQoxEEZlBcMLGvz2hBv7GXLdemaqJ7UyGZ3s hxgui5JgMdqovuR03tRW15X1isooWAj7A+mpWc1I/G+B/yL9piqP0DsNpPwtWZmy0uRALoDuN9jGF UaRpbmNDtva6d20NvTDOYWYB81KHiegs9PpG5Ore25A1sRoKNnLbAQadIZiSX9owM8/1h4cqEufdI N719zH/CpRmzXffTYDtwSA==; Date: Wed, 03 Sep 2025 14:57:13 +0300 Message-Id: <867byflpeu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <217ebef0-4b97-47a3-8118-ed1e8c176852@HIDDEN> (message from Dmitry Gutov on Wed, 3 Sep 2025 00:21:09 +0300) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> <217ebef0-4b97-47a3-8118-ed1e8c176852@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <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 (---) > Date: Wed, 3 Sep 2025 00:21:09 +0300 > From: Dmitry Gutov <dmitry@HIDDEN> > Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org > > On 02/09/2025 22:45, Dmitry Gutov wrote: > > We need a fuller scenario. If not with code, then a full use case > > described in English. > > Maybe to start something, do we expect some Comint functionality to be > broken when background threads exist and perhaps call > 'accept-process-output' with nil, in a loop? > > Such as comint-redirect-results-list-from-process or comint-proc-query, > for example. If the process is locked to the thread which runs comint-redirect-results-list-from-process, I wouldn't expect problems there. But it would be good for someone to look into this, sure. > Or among third party code, inf-ruby-completions. All of these call > 'accept-process-output' with their own process object. Same, I think.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:54:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 07:54:39 2025 Received: from localhost ([127.0.0.1]:39049 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utm4U-000583-MT for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:54:39 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42286) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utm4S-00057o-3k for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:54:36 -0400 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 1utm4K-0002mJ-Gs; Wed, 03 Sep 2025 07:54:28 -0400 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=XwbGwOBkkYLoW5m3FW5jyfac16KJjpQIaZpjJynxoMI=; b=VGMER8AEc7tY QeAaLpDDgBu8JRzebU88JRW5cvtUEFVt8zUxPYzhPmRO0Ex80xjll8E8LXYUs54j628+7C5VlYlYc H/+quaSf4xJucS9rBvxL99LO84UQEaghGdjxaAXmSs6RgJ3COoKfz61qNsNcza6lHRaImpd6+MYMf 37vPn+pbb66V3yYM8uCGfoamZ9nDl3I5iGy2ls9x2Dye4++Jqswiri6ND5haIQnkAMJGbUoD52LCr 8i+9jpxW345sG6YGQQGXb+ekgoOHdnspOwBpbzucDL4QBZ2QtuJbaxuR/HNbuUmvNpg0Ct1nKLcYG /sxTHLKeoSsDgYVl2+qslA==; Date: Wed, 03 Sep 2025 14:53:42 +0300 Message-Id: <868qivlpkp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> (message from Dmitry Gutov on Tue, 2 Sep 2025 22:45:54 +0300) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <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 (---) > Date: Tue, 2 Sep 2025 22:45:54 +0300 > Cc: sbaugh@HIDDEN, i@HIDDEN, 79367 <at> debbugs.gnu.org > From: Dmitry Gutov <dmitry@HIDDEN> > > On 02/09/2025 22:18, Eli Zaretskii wrote: > > >> I do believe that when a change in a long-standing implementation causes > >> an immediate issue we first consider reverting, especially when there is > >> no consensus on the approach. > > > > No, we don't. Reverting is actually the last resort, reserved for > > plain and clear mistakes, and for changes that cause grave regressions > > and cannot be fixed soon enough. > > A "mistake" is often in the eyes of the beholder. The lack of consensus > is something more objective. I said "clear mistakes". Those aren't in the eyes of the beholder, they are clear to everyone. > > . if the process on behalf of which we called > > server_accept_connection was not locked to some thread, undo what > > make_process did to the new process when it called pset_thread > > . otherwise, call set_proc_thread to lock the new process to the > > same thread as the one which caused this call > > Sounds about right. Thanks, will do. > >> I don't want us to spend a lot of time arguing revert-or-no-revert now, > >> but could you, Eli, try to decide on a full example of a buggy scenario > >> which is really solved by thread locking being? > > > > I already described that in so many words. That is all I can afford. > > We need a fuller scenario. If not with code, then a full use case > described in English. I described some of them, and just now posted a list of my messages in bug#79201 where I did that. That's the best I can afford doing at this time, sorry. > I'm pretty sure more of your time is being wasted on answering the > emails with objections. Regrettably. Yes. And I still consider this a worthwhile investment, if as result we will become on the same page regarding how the relevant code works and what should be our expectations from it. > > And please keep in mind that processes were being locked to threads > > since day one, just incompletely so. I didn't invent it just > > yesterday out of the blue: it's the original design of processes with > > threads. > > IIUC the existing protection did very little in practice, all of these > years: it only stopped some thread calling 'accept-process-output' with > an explicit reference of a process belonging to another thread. That's not "very little" at all. And if some Lisp program called set-process-thread, it would do exactly what is now done by default. > Any kind > of buggy code would have to try hard to obtain that reference in the > first place - so that would almost never happen anyway. The new > protections seem a lot more strict. Yes, it is stricter. Because that's the intent, as is clear both from the code and from the documentation, and also because it makes Lisp programs much easier to reason about. I also don't quite see a disaster this change is causing to code which disregarded the documented restriction. All we had till now is a single bug report, which clearly indicates that my change was incomplete, and is easy to fix. I fail to understand the amount of excitement due to a change that turns out not to be different from many other changes we make in development. Here's one recent example: https://lists.gnu.org/archive/html/emacs-devel/2025-09/msg00002.html This even broke the build, which is clearly a serious regression. And the solution was that Mattias quickly installed two followup changes; case closed. Good job, Mattias! > TBC I think we should continue to support locking, and your current fix > seems productive in this regard, but whether locking should be by > default is not obvious to me - and at least two smart devs who worked > with Emacs Lisp threads say no. That seems like grounds to re-evaluate. > Even if we reach the current default we'll have documented our > conclusions better rather than just saying "this is so". I'm not saying we cannot revisit the decision to lock processes to threads. But given that the original design and implementation clearly tell us that was the intent, I think we should start from what we have, and only change it if we decide that the current default is wrong in too many important cases. For now all we have is 2 cases: one was solved yesterday by unlocking the process, the other is the one discussed here, which uncovered a flaw in the change I installed, and should be easy to fix. That's not enough to declare the idea of locking wrong as the default, let alone bankrupt. For such a far-reaching conclusion we need much more data points, of both kinds. My knowledge of this code and my experience, based on 12 years of developing, maintaining, and fixing bugs in it, is that letting random threads read output from subprocesses causes many unexpected behaviors and thus triggers subtle bugs and non-determinism in seemingly valid Lisp programs. You think differently, but please don't dismiss my opinions on this too quickly, given my familiarity with the code in this area and the amount of time I spent on it.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 3 Sep 2025 11:26:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 07:26:32 2025 Received: from localhost ([127.0.0.1]:39018 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utldI-00018o-CW for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:26:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44440) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utldF-00018a-9q for 79367 <at> debbugs.gnu.org; Wed, 03 Sep 2025 07:26:30 -0400 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 1utld7-0005eC-D7; Wed, 03 Sep 2025 07:26:21 -0400 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=2Awzy4dOtTuhIiZZ0dZ7fxMw/8dzW18h0lszy+NGizw=; b=h4uaJz1uARJN SKvT2d5pt/ulwPNNjFGxLYg65oJmE8OXIWbVfqSLUP9MJHErVwURVUivivdiZsLyS4FZK/bWdvfEL LLU9l23rNfHIc+WXocByx0khOwW5EtaACxdZzd8daXRZBUrtEoo+w+yGmqBZFdd0pvg2gMYyAaYi7 FZ77MXIUTVtaESK9NdTJGZ5wqye1DhMgy5h03W0ZIxahgDoA+5hmAS0MOSCogwFmFwN8RiwlFKtOM WICroLtFSVCj5/Z/ap3eMlHeFd3X8iWXjmYd/MSICwokRYvu/h+/TBYT/xiZziMmsqFc7riBGZhpY KJkYPD7Hp/RSQ3SjQZu0dw==; Date: Wed, 03 Sep 2025 14:25:58 +0300 Message-Id: <86a53blqux.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierfrd4ejj9.fsf@HIDDEN> (message from Spencer Baugh on Tue, 02 Sep 2025 15:33:46 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <ierfrd4ejj9.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: Dmitry Gutov <dmitry@HIDDEN>, i@HIDDEN, 79367 <at> debbugs.gnu.org > Date: Tue, 02 Sep 2025 15:33:46 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > I can code the proposed fix in a few minutes, if there's agreement to > > what I proposed to do. I'm still uncertain what I proposed is > > agreed-upon. So let me reiterate that: > > > > . if the process on behalf of which we called > > server_accept_connection was not locked to some thread, undo what > > make_process did to the new process when it called pset_thread > > . otherwise, call set_proc_thread to lock the new process to the > > same thread as the one which caused this call > > Whatever you do, please post your change for review rather than just > pushing it. Will do. > >> I don't want us to spend a lot of time arguing revert-or-no-revert now, > >> but could you, Eli, try to decide on a full example of a buggy scenario > >> which is really solved by thread locking being? > > > > I already described that in so many words. > > Can you send that full description again? Perhaps I can translate it > from words into code for you. Look at my posts as part of discussing bug#79201. For example: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#88 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#94 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#100 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=79201#106
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 21:21:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 17:21:28 2025 Received: from localhost ([127.0.0.1]:36978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utYRQ-0006ID-OL for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 17:21:28 -0400 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:60157) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1utYRK-0006GB-0I for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 17:21:21 -0400 Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfhigh.phl.internal (Postfix) with ESMTP id 7429914001AA; Tue, 2 Sep 2025 17:21:12 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-01.internal (MEProxy); Tue, 02 Sep 2025 17:21:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756848072; x=1756934472; bh=OBOBMaMvP0o6eGthMVOXGtXrI+2rV3KN301xapYXi+U=; b= sgAnLPfGjl7VEexbo3xk+BFVzAjPwYgjjjjJ/yBazP+dWfY5Wv0z9H2Q0Wy/bcgt uvuRiaWEEp6qpy6gDTlclX71AsoFAJG79JxqaaKHhw+wvKcLVWJa7VR601TloZCV UxtTr2s5QhUzJP7D/eKPNjs36LFs1T21SfvGvVhNDO2xgNjOm2omuIhq/tIV40Qd ju4bBVRaTkyitfbjp9K03FJovCco5C2mlaKxwFXl4aaGB7DjD7vRsuuL7kA4nLfm +hOYP39j0JhmeLiLwELYwH8mYgDzs27WqGtqPBApG+FduXDYUM8uAHQIKpIuMfXp 2yUtT0ukV9IGqEf/KM7Pbw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756848072; x= 1756934472; bh=OBOBMaMvP0o6eGthMVOXGtXrI+2rV3KN301xapYXi+U=; b=l 6JbM+r+LkHv7j6qM6X2L9WV75nJ+uTFGW4orLBaGSlY1JFh3yOqjZtvNV19hzQIp rtxWT5isv/ndo4MBeC3IIRQnv6eqSTUay/WBOA3jXkH7Hs0+wLV2epGnuY+6DI/z xFvIja+PN5xV4lLMatAu0kucYl1v+XXayCZFgSSbXsdafPPiwdH/r+9uhjWMDsAf 5+iKwV5e+7n8CPxCSATcJUH8d1h2r2BoB0A2gKPqFcGqaz3t/SKnSb+fTkeOLwPu 6beXiAXkPCmVghx2lg6Ec0erzyEgij5GCXgs0g95I6bio+rbWOvFf2VTNUQgq2IX p4eiqxB4BVB1HAUebAXRQ== X-ME-Sender: <xms:x1-3aDW8G3g4hPMFpw0s92pXQZn2SAlmiLm_scqaX6Tkb3IqqS-oEw> <xme:x1-3aGLOrPOI0wzs-i_sjcZ-EvZvAFlZ1HKTtvOzUQ4yAcNP8HkN8Jz3AaPJWOfst 48h6hvy-W2en9zVESM> X-ME-Received: <xmr:x1-3aL_5dxlBbQBUIsWUc7tSQFg_9kIydPTa-ZQXRvj_QpuOayrca0pB1np7Cmjvc9ep> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddufeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffhvfevfhgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epkeefudefgfejffefvdfhteegveevhfekkeekhffgudfhveejteffhfegueetgefgnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehisehfuhiihi drmhgvpdhrtghpthhtohepshgsrghughhhsehjrghnvghsthhrvggvthdrtghomhdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: <xmx:x1-3aBImzC0qdohf19-RIusTrCcZB85IRLVmXHO3gTCn3xFSi77gdg> <xmx:x1-3aImvTu2k6UwLFhvVWG5Vp4LuVWBRqA6TVnaV1a6ncHGmvMkRtQ> <xmx:x1-3aNPmbOTSpWfTwVnTvXVs8vmSPT8qRSi3xZCTFAv2X8TNVhVIGQ> <xmx:x1-3aG3AcPk0Ipxa7KFu_35PaMv4POYKh2n2eun3GD9XvFlwapo_nA> <xmx:yF-3aF-S41gx86a-4BuMyP955kiOxxaw3Doz_jQU6TwlCe81srzWyMAs> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 17:21:10 -0400 (EDT) Message-ID: <217ebef0-4b97-47a3-8118-ed1e8c176852@HIDDEN> Date: Wed, 3 Sep 2025 00:21:09 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t From: Dmitry Gutov <dmitry@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> Content-Language: en-US In-Reply-To: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 02/09/2025 22:45, Dmitry Gutov wrote: > We need a fuller scenario. If not with code, then a full use case > described in English. Maybe to start something, do we expect some Comint functionality to be broken when background threads exist and perhaps call 'accept-process-output' with nil, in a loop? Such as comint-redirect-results-list-from-process or comint-proc-query, for example. Or among third party code, inf-ruby-completions. All of these call 'accept-process-output' with their own process object.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:46:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 15:46:08 2025 Received: from localhost ([127.0.0.1]:36743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utWxE-0001o9-6K for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:46:08 -0400 Received: from fout-a5-smtp.messagingengine.com ([103.168.172.148]:33917) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1utWxA-0001nK-IM for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:46:06 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfout.phl.internal (Postfix) with ESMTP id 07EC3EC05A6; Tue, 2 Sep 2025 15:45:58 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 02 Sep 2025 15:45:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756842358; x=1756928758; bh=XKeT7xX+v2P7fX5QlGQeJIrypRtQRBV9P+xWIT4q89M=; b= CNk6FEMKYe5HcAUHdVDSIsZJmMpYFrY90SmvjWHhKkFMt4hedaslHcdFlMYsrHTM Mo2/rzHnEOQeabfIS0IEzPA6cvOgwlxbUa3JedNipHWsdqG5xl5qNi8LFUy3AFdQ zAvJbVuipcieDnzObFCbzdFB90e3epgNS0HkqK2WsOAW9DL3Cnt3gZ0TPMy39Q3J rFgrNLyTghKkCXbSFRtgJfvDgrreomDWa/FHHzi8QXwphOPf2Z7JXk83VUarPYmj wpf2zGzP/bS78frPzQmvwB/kWZ+en3fkBILz/85BFJFqYcuYB00GcXLc1AiygABw RBJ+Mf0pR9OVvcHebAt62A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756842358; x= 1756928758; bh=XKeT7xX+v2P7fX5QlGQeJIrypRtQRBV9P+xWIT4q89M=; b=Q GZb8kgn4acr3J+BDL+xfe6d4wty2szznt+hogpzDBbZTR4VmhpzJEfPC1MWle6gF PmD4oP++zBf1TKNiC42qB0wEv5/RGs89zcLlyav85dSyY61Rx/pAa/WRx6DuX+Gs T1pmTX3sSunz/7WPmCd00kqdtujKFqX9jmUPaemmt5nY5NsXoRJRQudIr2fwOFuN 0/u8FhjL7DnumZAnDfIPIWCkEDUeV4gBXOE41x4bbnLUTNh2TBjZLQBnSmVtHF2G 9ki8UXIQdghtHfiVlzTfxdgoHSQoU5aO5oRQXXx8lFVjP2Djy4pEcllfZttBXMZx IsSkAOlFt/8EWrvEdDeXA== X-ME-Sender: <xms:dUm3aDyUfZ-olVyHzx1uo4AO85ZNl5SQNVF03a0kZxY7DhvfRBrh0g> <xme:dUm3aF0T4Nja9tFyMM7x4A1U375Xy4iZho4lz-qTjZwaKzvsorZj4XTq9tJfkbeI_ hzhdXYkGR55vupOpPA> X-ME-Received: <xmr:dUm3aJ7aqQFdfRc3zzr30R4Qb4lfe5fQTDuqwJL0Wjje6hGsOdc4TpAg4qUrtirG9Eeh> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurh epkfffgggfuffvvehfhfgjtgfgsehtjeertddtvdejnecuhfhrohhmpeffmhhithhrhicu ifhuthhovhcuoegumhhithhrhiesghhuthhovhdruggvvheqnecuggftrfgrthhtvghrnh epteduleejgeehtefgheegjeekueehvdevieekueeftddvtdevfefhvdevgedujeehnecu vehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepughmihhtrh ihsehguhhtohhvrdguvghvpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhu thdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghh esjhgrnhgvshhtrhgvvghtrdgtohhmpdhrtghpthhtohepihesfhhuiiihrdhmvgdprhgt phhtthhopeejleefieejseguvggssghughhsrdhgnhhurdhorhhg X-ME-Proxy: <xmx:dUm3aAU_pYpZ2Q47QS9qnW_7SLRGvPdgh2NFDNQcnIBHg36joI_dkA> <xmx:dUm3aAChLDxp4XqdHSdB5p4-NJW6lzfueO75BN2ZKelG-dtE32qD2w> <xmx:dUm3aH6gkatS6Fh5RabsjoYWL2YB2CETq31lzcXCfSrw3hhtTnKBFg> <xmx:dUm3aDxwhzYRyKbsKrsT--8m3i4pOcS8kUKzTJRSh4FQrlIyKcFuIQ> <xmx:dkm3aB5nzNnwyukQSSvssrkDPC9gWiDMJH9QTr76bg3I4qUhqVEQYfzg> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 15:45:56 -0400 (EDT) Message-ID: <5fcce6c2-3be4-4bc8-9ab8-81c19c3038cc@HIDDEN> Date: Tue, 2 Sep 2025 22:45:54 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t To: Eli Zaretskii <eliz@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86cy88ll37.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 02/09/2025 22:18, Eli Zaretskii wrote: >> I do believe that when a change in a long-standing implementation causes >> an immediate issue we first consider reverting, especially when there is >> no consensus on the approach. > > No, we don't. Reverting is actually the last resort, reserved for > plain and clear mistakes, and for changes that cause grave regressions > and cannot be fixed soon enough. A "mistake" is often in the eyes of the beholder. The lack of consensus is something more objective. >> A one-liner change is probably not a big deal by itself, but like >> Spencer said, the new process should at least follow the locking of its >> original thread, or something like this. And we still don't have a >> proposed fix on that. > > I can code the proposed fix in a few minutes, if there's agreement to > what I proposed to do. I'm still uncertain what I proposed is > agreed-upon. So let me reiterate that: > > . if the process on behalf of which we called > server_accept_connection was not locked to some thread, undo what > make_process did to the new process when it called pset_thread > . otherwise, call set_proc_thread to lock the new process to the > same thread as the one which caused this call Sounds about right. >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> but could you, Eli, try to decide on a full example of a buggy scenario >> which is really solved by thread locking being? > > I already described that in so many words. That is all I can afford. We need a fuller scenario. If not with code, then a full use case described in English. I'm pretty sure more of your time is being wasted on answering the emails with objections. Regrettably. > And please keep in mind that processes were being locked to threads > since day one, just incompletely so. I didn't invent it just > yesterday out of the blue: it's the original design of processes with > threads. IIUC the existing protection did very little in practice, all of these years: it only stopped some thread calling 'accept-process-output' with an explicit reference of a process belonging to another thread. Any kind of buggy code would have to try hard to obtain that reference in the first place - so that would almost never happen anyway. The new protections seem a lot more strict. TBC I think we should continue to support locking, and your current fix seems productive in this regard, but whether locking should be by default is not obvious to me - and at least two smart devs who worked with Emacs Lisp threads say no. That seems like grounds to re-evaluate. Even if we reach the current default we'll have documented our conclusions better rather than just saying "this is so".
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:33:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 15:33:55 2025 Received: from localhost ([127.0.0.1]:36692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utWlO-00017Z-Ra for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:33:55 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33239) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utWlM-00017D-QJ for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:33:53 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86cy88ll37.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Sep 2025 22:18:20 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> <86cy88ll37.fsf@HIDDEN> Date: Tue, 02 Sep 2025 15:33:46 -0400 Message-ID: <ierfrd4ejj9.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=1756841626; bh=JRzHPoLT4PdummGV531oC9k+7QsTxIto69rU4506O1U=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=NAAwL+mWfvNS28YKGhPGG+v+kMjaYLZAGNc6kProCvXu8eiFDkgQdm8imB0AxcKTx 9kdajzRHkEhKl9TBk80yjLjlK1cd5SdoZSuNTGLiOBcNwrW5nIUnHO3WAej6XmKg0d 5bdyE/lA0tea1Ap0R+sUauhSa+1Pw3SEMB/O9h38eWyZKUAXPoewN8S9B5YvDuHLcv qv4KH0baFzL9nlXVntDmjPpepNSkMzTO9V1r6mWNSEyTmHiGs+aRjfvIyQyNsz4Thk LZsfVYw66NYwl4ujX6nIRvy5SsOUyMXRwfL1bs430OWI/haXnjF2aw/fVVE8DcYKy4 amA922l8V8Lkw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, Dmitry Gutov <dmitry@HIDDEN>, 79367 <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: Tue, 2 Sep 2025 19:28:05 +0300 >> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org >> From: Dmitry Gutov <dmitry@HIDDEN> >> >> > This particular breakage is simply because my change was incomplete: >> > it left some processes not locked to their thread, and the solution >> > proposed by the OP, which fixed that blunder, is simpler and has fewer >> > downsides than backing out the process locking to threads. This >> > happens all the time in development, and the conclusion is rarely that >> > the original changes should be backed out, certainly not if there are >> > simpler fixes. >> >> I do believe that when a change in a long-standing implementation causes >> an immediate issue we first consider reverting, especially when there is >> no consensus on the approach. > > No, we don't. Reverting is actually the last resort, reserved for > plain and clear mistakes, and for changes that cause grave regressions > and cannot be fixed soon enough. > >> A one-liner change is probably not a big deal by itself, but like >> Spencer said, the new process should at least follow the locking of its >> original thread, or something like this. And we still don't have a >> proposed fix on that. > > I can code the proposed fix in a few minutes, if there's agreement to > what I proposed to do. I'm still uncertain what I proposed is > agreed-upon. So let me reiterate that: > > . if the process on behalf of which we called > server_accept_connection was not locked to some thread, undo what > make_process did to the new process when it called pset_thread > . otherwise, call set_proc_thread to lock the new process to the > same thread as the one which caused this call Whatever you do, please post your change for review rather than just pushing it. >> I don't want us to spend a lot of time arguing revert-or-no-revert now, >> but could you, Eli, try to decide on a full example of a buggy scenario >> which is really solved by thread locking being? > > I already described that in so many words. Can you send that full description again? Perhaps I can translate it from words into code for you.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 19:18:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 15:18:35 2025
Received: from localhost ([127.0.0.1]:36669 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utWWY-0000LN-Fb
for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:18:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:32862)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utWWV-0000L0-U7
for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 15:18:32 -0400
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 1utWWM-0002Ts-9w; Tue, 02 Sep 2025 15:18:25 -0400
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=e0K8wDtAQ8Nc2gKupltmOGBdVKYKvSzXphET6jM/zNQ=; b=NUE28I3IbG3+
wWCelo9lYyyhNAYMRl7Tos8Oie0EMHI3jSReusWg0A6HHGAvccuqmBBEU+sMF8TwUt6YmuF9P7py8
OqPk8a8+WodOLzP+L03ti9oFDOe02Jtx6+Xrs0byd00kiHRxzYHRHp/zPKbyMNvdCzxaDezLiof5h
vtwLlEUesFgiLyu7JktuOTdKp3bd9zTddoQGFq7G884A4ZAhcRLcICNxy6EdhLt6X2apthLZoOoZp
RguAqVlDyCgV98ZxRYPwh5CotSygcrQvywkuBXOxdSkFDf+LJDzfTcPYpG3Zhc/8RIE7XmOoigyqw
eh8bLh+f4SFmnXlZ85Qlgw==;
Date: Tue, 02 Sep 2025 22:18:20 +0300
Message-Id: <86cy88ll37.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Dmitry Gutov <dmitry@HIDDEN>
In-Reply-To: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> (message from
Dmitry Gutov on Tue, 2 Sep 2025 19:28:05 +0300)
Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN>
<ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN>
<ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN>
<8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 79367
Cc: i@HIDDEN, sbaugh@HIDDEN, 79367 <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 (---)
> Date: Tue, 2 Sep 2025 19:28:05 +0300
> Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry@HIDDEN>
>
> > This particular breakage is simply because my change was incomplete:
> > it left some processes not locked to their thread, and the solution
> > proposed by the OP, which fixed that blunder, is simpler and has fewer
> > downsides than backing out the process locking to threads. This
> > happens all the time in development, and the conclusion is rarely that
> > the original changes should be backed out, certainly not if there are
> > simpler fixes.
>
> I do believe that when a change in a long-standing implementation causes
> an immediate issue we first consider reverting, especially when there is
> no consensus on the approach.
No, we don't. Reverting is actually the last resort, reserved for
plain and clear mistakes, and for changes that cause grave regressions
and cannot be fixed soon enough.
> A one-liner change is probably not a big deal by itself, but like
> Spencer said, the new process should at least follow the locking of its
> original thread, or something like this. And we still don't have a
> proposed fix on that.
I can code the proposed fix in a few minutes, if there's agreement to
what I proposed to do. I'm still uncertain what I proposed is
agreed-upon. So let me reiterate that:
. if the process on behalf of which we called
server_accept_connection was not locked to some thread, undo what
make_process did to the new process when it called pset_thread
. otherwise, call set_proc_thread to lock the new process to the
same thread as the one which caused this call
> I don't want us to spend a lot of time arguing revert-or-no-revert now,
> but could you, Eli, try to decide on a full example of a buggy scenario
> which is really solved by thread locking being?
I already described that in so many words. That is all I can afford.
And please keep in mind that processes were being locked to threads
since day one, just incompletely so. I didn't invent it just
yesterday out of the blue: it's the original design of processes with
threads.
And if that is not good enough for you, then we will have to agree to
disagree, and leave it at that. I stand by my opinion.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 16:28:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 12:28:18 2025 Received: from localhost ([127.0.0.1]:36254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utTrm-0000OE-F8 for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 12:28:18 -0400 Received: from fhigh-b4-smtp.messagingengine.com ([202.12.124.155]:33449) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dmitry@HIDDEN>) id 1utTrj-0000Nx-Jg for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 12:28:16 -0400 Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id B95257A035C; Tue, 2 Sep 2025 12:28:09 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Tue, 02 Sep 2025 12:28:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1756830489; x=1756916889; bh=AM6rYsZq7bdodL3fnRCEBD1aJXyM4d7GuLbbKNYLFlU=; b= OzW98nSWctnHfNf+kHuEbnPQJmRXtuV4KTGnE/qGbej+GZlRoJHTJPw95uvckItL /dAxU3f4SBZ5C4BYeEyKetyTAz4Kb035G6ZPd5VQr+vhsuYVLIOWIrlZmWGsCyB1 FF5etpG+Fc4pnNPR+t5/BH355V7bODQoKD8Uag8lXh8FXVtJmmX/QBbsThqm6WR/ SRWd7/BRPTnaSW4YBVyrVypY8KP4mS3Xq3eI4k9dVQ9lzT2m9rvkMTWH/gj1k5NN 7OITsbL1ezNpZeBQifnz05Ofk65WeNp1ZHNYKshqR6cIt6/7YtsaOJG1KNhRXYYt qSC4C6owZBvKe+xB0y/rCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1756830489; x= 1756916889; bh=AM6rYsZq7bdodL3fnRCEBD1aJXyM4d7GuLbbKNYLFlU=; b=Q mBjOMmrIZeiu9uQ+ODS6jKIGS/OIJYgQLnYQiNhUblnG08UJhxE+Z3aXVvBrn1CS KXELXL2T+rept3w0fmegHUEuUXQNT94bife8mq3SUrfInT0bJIb9Jxz4EoQtFMMg 8ulRMP9NfffCLe+10TQLF21JRquYPlKuyFGGLivRLqBcoiG8Lc2vGFQOaAjhuVYp HiEAOfgqe6PirkwntpqLmXrC6oC+c9nbX9s8PohyIgl1pIhOR8VvR7xL+vcMBcGt 6wlq+dyGidW2pd761o8eGyiKWUnWwqFTPCxyp4lilSBacAjZpvLEzPWubjND46FB s7RiOeWygtZnCYziUQ1KQ== X-ME-Sender: <xms:GRu3aIh8rioE6-wF_lyAxaaN3kz2xy990eKH2dipWELlow6foLSo9w> <xme:GRu3aLlDdxt_9ltAFgs1V1Vk4cCDRwvZEJmLsLgTYfD8_Gd9hMTQbY9SO0-jcbko7 b_VnDikr-KZsGqE6LE> X-ME-Received: <xmr:GRu3aMoZTI7RkDb06vKecux-EdnJy-IX9gjhXo8WrWvLdj5AOBxllTWtgHU0dOFGbgCG> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdejgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegrihhl ohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpe fkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepffhmihhtrhihucfi uhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtthgvrhhnpe etudeljeegheetgfehgeejkeeuhedvveeikeeufedtvddtveefhfdvveegudejheenucev lhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhi esghhuthhovhdruggvvhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtphhouhht pdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtohepshgsrghughhhse hjrghnvghsthhrvggvthdrtghomhdprhgtphhtthhopehisehfuhiihidrmhgvpdhrtghp thhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrgh X-ME-Proxy: <xmx:GRu3aMGsC5XTSJvg7MUecCYEtF22BDi8Lmt2Hzvjwsqxn460QOOWpQ> <xmx:GRu3aAxCsOHQ5Sgq09880mxP8fN-2aYW7XskJAinl0qcQKr00B_OqQ> <xmx:GRu3aJr6XUZIoQoS42F4YhOSLGSzdejmqjDCUIWo2V0Fw0YyUWJKSw> <xmx:GRu3aCj2ThKi02xHesu-V8Np86HSmkP961x2MfnvQ-ZvlKAMCACuTA> <xmx:GRu3aMprdS3ghITfBNjGl50u36VJmeWn2_fuwJdJLDSfU7DWIB49Nuw7> Feedback-ID: i07de48aa:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 2 Sep 2025 12:28:07 -0400 (EDT) Message-ID: <8b2b19fb-e7a7-430d-99c0-b4fe70ad02cb@HIDDEN> Date: Tue, 2 Sep 2025 19:28:05 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t To: Eli Zaretskii <eliz@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> Content-Language: en-US From: Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <86qzwolwxc.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) On 02/09/2025 18:02, Eli Zaretskii wrote: >>>> If that doesn't fix it (or you already had that commit), can you try >>>> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >>>> c93be71e45d4cebeb017c813426228e579e9381d and test again? >>> What will that prove? Those changes are not going away, so trying >>> that is just wasting everyone's time and energy. I thought we were >>> past that... >> No, we're not past that, I still think those changes are wrong. >> Especially because this bug report shows that those changes are indeed >> breaking existing code. >> >> I repeatedly said that those changes would cause new issues to be >> reported, and now it is happening. Maybe it doesn't convince you that >> the changes need to be reverted, but you should at least be giving it a >> little more credence now. > This particular breakage is simply because my change was incomplete: > it left some processes not locked to their thread, and the solution > proposed by the OP, which fixed that blunder, is simpler and has fewer > downsides than backing out the process locking to threads. This > happens all the time in development, and the conclusion is rarely that > the original changes should be backed out, certainly not if there are > simpler fixes. I do believe that when a change in a long-standing implementation causes an immediate issue we first consider reverting, especially when there is no consensus on the approach. A one-liner change is probably not a big deal by itself, but like Spencer said, the new process should at least follow the locking of its original thread, or something like this. And we still don't have a proposed fix on that. I don't want us to spend a lot of time arguing revert-or-no-revert now, but could you, Eli, try to decide on a full example of a buggy scenario which is really solved by thread locking being? Like, one that you consider a prime example. The present bug report doesn't count, since it's caused by an incomplete implementation. We'll need a specific piece of Lisp code, to be able to try different underlying implementations with it. So far I see two significant reasons to default to locking: - When we have scheduled some code to run on a different thread (filter/sentinel), there is no simple way to switch to a previous thread, to run it there. Unlike with the current buffer, for example. - Enabling locking later if a process starts without being locked to a thread, could be error-prone. But both only really work only if we understand specific problems being solved by locking in the first place.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 16:13:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 12:13:47 2025 Received: from localhost ([127.0.0.1]:36171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utTdh-000817-Tn for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 12:13:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42624) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utTde-00080Z-5e for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 12:13:43 -0400 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 1utTdX-00046e-L7; Tue, 02 Sep 2025 12:13:35 -0400 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=dSZLzc66Xao7KxElhEciBVMNGLVmOkK9+wnW0v6y1K0=; b=sQSmhd6CF0kq hiffB9Pb0oiU3tfHMLAMRwBzW4SPZJSc47eQ4fnEA2yek8o+h+1EC/4+2LEaMVHC9HKhBQFz7ahrS YUwJ28REMlKwEzSCiLml0onida4HdJMG7B7OggVGZytAum+UfDIqF329i3CqPxGAHL+3ZQwRGDJow erRQsxupB8TNF/NtLGBnbSflYYeG/o22Z/PJOFKi7StO5a2Sl+Ewp6xloADII9Zqc74WSRlPWId5h K0vB6FMJrHN5/VYsbViya11fWBduMyv5M4EtqSdMe5P4W7kPKkbJmUcdMgdgUidFpeddbiT90BoAz Zh7qmg91pNmHkIDCg7YZSw==; Date: Tue, 02 Sep 2025 19:13:32 +0300 Message-Id: <86ldmwltn7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierfrd4napy.fsf@HIDDEN> (message from Spencer Baugh on Tue, 02 Sep 2025 11:19:21 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> <ierfrd4napy.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org > Date: Tue, 02 Sep 2025 11:19:21 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> > And why do you think this thread is a random one? If everything works > >> > as intended, it is the thread which created the existing process, > >> > because the descriptor whose presence in Available triggers the call > >> > to server_accept_connection is one of those on which pselect waited, > >> > and should have belonged to the current thread. > >> > >> Not if the existing process was unlocked. Then this is a random thread. > > > > Then let's fix the case of an unlocked process (which AFAIU is not > > what happened here). But if the process was locked to a particular > > thread, as that is the default, then do you agree that this code > > should be run by that very thread, at least nominally? > > Yes. > > But we can't rely on that since of course the process could be unlocked. > Our code needs to behave correctly in both cases. If you mean the case where the original process was not locked to any thread, I agree: the fix should include both cases. It is easy to distinguish between a process that wasn't locked (in which case the new one shouldn't be locked, either), and the case where it was locked to a thread. If you mean something else, please elaborate. > > This particular breakage is simply because my change was incomplete: > > it left some processes not locked to their thread, and the solution > > proposed by the OP, which fixed that blunder, is simpler and has fewer > > downsides than backing out the process locking to threads. This > > happens all the time in development, and the conclusion is rarely that > > the original changes should be backed out, certainly not if there are > > simpler fixes. > > That's true, but that doesn't change the fact that your change was > broken and caused this bug. This happens all the time in development, to all of us. When it does, we install follow-up changes to fix the regressions. We don't usually revert the original ones, unless we learn that their ideas are unworkable, or cause much worse problems. This is not that case, not yet. > And I am annoyed that I have to debug issues caused by your own > broken changes while you refuse the simple solution of backing out > the broken change. It happens all the time in Emacs development that someone makes a mistake and someone else needs to debug and fix this. If you are annoyed in this case, just leave the debugging to me. Unlike some other people who make changes and disappear, I'm here, day in and day out, and when a bug due to my changes is reported, it is usually very high priority to me. (In this case, I responded within an hour of reading the bug report. Before you did, btw.) But backing out changes is not a "simple solution", because those changes were made for a reason. > Could we at least turn off your change by default, if we can't back it > out? I would be happy to add code to do that. That will give us more > time to iron out the issues with it. If we turn this off by default, then any problems, like this one, which need to be fixed as followup, will never materialize. So I must say no in this case. (I also don't think this strategy is correct in any software development in general.) If your use cases suffer from this, you can use set-process-thread to unlock your processes, as a stopgap. Although I would encourage you not to do that and report the problems instead, so that they could be debugged and fixed ASAP.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 15:19:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 11:19:33 2025 Received: from localhost ([127.0.0.1]:35793 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utSnE-0004w2-E2 for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 11:19:32 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60529) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utSn9-0004vk-Dz for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 11:19:28 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <86qzwolwxc.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Sep 2025 18:02:39 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> <86qzwolwxc.fsf@HIDDEN> Date: Tue, 02 Sep 2025 11:19:21 -0400 Message-ID: <ierfrd4napy.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=1756826361; bh=fbjJS1RyxdctTeA4nrr6IFCwIJvKOZz/f7pX33w3GZ8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=r41IxPOeeKZ4tU4k0SIzkBWMLDtDHqHyCOrXhXR3imPAhjewYrSuoHL79czaz3X58 xUcjhEHs0LTeIdou574DZdwu2i7YcLzfjuzqqpgEOC323U65y3Yh4bnXk8I/4Sjdzh EshKTd/M+9r2QX3Sd27ryqMYVVRIkgzmG1n65n5eVWkR0n50Qjw9LngMKbsDCOvL19 +PQCAKUS67gkeLuMY/jMip8oaQwKcHwIWgrgcT6iWI1NnMft6tBly0VmP2FeT0tOqi mIP8RMuNghFuknkVQygd4HUXyqymkIjQcKfKvGUKe3gnHihCXpi83hmU+LElcCvfUc BrL3SoEngsoAQ== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org >> Date: Tue, 02 Sep 2025 10:33:12 -0400 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> > But make_process, called by server_accept_connection, already did >> > this: >> > >> > pset_thread (p, Fcurrent_thread ()); >> > >> > So if we want to lock this new process to some other thread, we should >> > fix that part as well to be consistent. >> >> True, that's a bug. >> >> > And why do you think this thread is a random one? If everything works >> > as intended, it is the thread which created the existing process, >> > because the descriptor whose presence in Available triggers the call >> > to server_accept_connection is one of those on which pselect waited, >> > and should have belonged to the current thread. >> >> Not if the existing process was unlocked. Then this is a random thread. > > Then let's fix the case of an unlocked process (which AFAIU is not > what happened here). But if the process was locked to a particular > thread, as that is the default, then do you agree that this code > should be run by that very thread, at least nominally? Yes. But we can't rely on that since of course the process could be unlocked. Our code needs to behave correctly in both cases. >> >> If that doesn't fix it (or you already had that commit), can you try >> >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> >> c93be71e45d4cebeb017c813426228e579e9381d and test again? >> > >> > What will that prove? Those changes are not going away, so trying >> > that is just wasting everyone's time and energy. I thought we were >> > past that... >> >> No, we're not past that, I still think those changes are wrong. >> Especially because this bug report shows that those changes are indeed >> breaking existing code. >> >> I repeatedly said that those changes would cause new issues to be >> reported, and now it is happening. Maybe it doesn't convince you that >> the changes need to be reverted, but you should at least be giving it a >> little more credence now. > > This particular breakage is simply because my change was incomplete: > it left some processes not locked to their thread, and the solution > proposed by the OP, which fixed that blunder, is simpler and has fewer > downsides than backing out the process locking to threads. This > happens all the time in development, and the conclusion is rarely that > the original changes should be backed out, certainly not if there are > simpler fixes. That's true, but that doesn't change the fact that your change was broken and caused this bug. And I am annoyed that I have to debug issues caused by your own broken changes while you refuse the simple solution of backing out the broken change. Could we at least turn off your change by default, if we can't back it out? I would be happy to add code to do that. That will give us more time to iron out the issues with it.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 15:03:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 11:03:01 2025 Received: from localhost ([127.0.0.1]:35640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utSXE-0003pH-RN for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 11:03:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54456) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utSX8-0003og-Ti for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 11:02:56 -0400 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 1utSX1-0007RL-Fm; Tue, 02 Sep 2025 11:02:48 -0400 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=oPMow9oF0MHZkIIUu2gikRKXgabNUWCoqVdo92V9NDs=; b=bYRIuhD4a77X 1IWJlMtdDU0yCF6GhZvB8dOCzUjYuK0biM6+766O9LwXF488rVsRXHjAcLSm3OeVc2EarUVSgABSL wybE/V/5BVdcMsR36yYIIkR8ZpNwB/fXzzTamICPee28mAGMJGimkGJ+XEKZycvl7bRZPkoDYjAQj IJViktsVxkM2Hj4cfdS7+rkh+U1wspO9+fK8BLSzUE5lVbCi3tjWwt81xQ4y8ZyOoQG4tSyCvrjLd FGuhPGL0fnyTDL2MM1m/THE9OeEgMkQH4a7BQ1FQGonV7LQVuwzt88PoTlUPVAjdq/I4/xZDqkh78 wGQB2/av191a7VyudMllEA==; Date: Tue, 02 Sep 2025 18:02:39 +0300 Message-Id: <86qzwolwxc.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierplc8ncuv.fsf@HIDDEN> (message from Spencer Baugh on Tue, 02 Sep 2025 10:33:12 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> <ierplc8ncuv.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: i@HIDDEN, dmitry@HIDDEN, 79367 <at> debbugs.gnu.org > Date: Tue, 02 Sep 2025 10:33:12 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > But make_process, called by server_accept_connection, already did > > this: > > > > pset_thread (p, Fcurrent_thread ()); > > > > So if we want to lock this new process to some other thread, we should > > fix that part as well to be consistent. > > True, that's a bug. > > > And why do you think this thread is a random one? If everything works > > as intended, it is the thread which created the existing process, > > because the descriptor whose presence in Available triggers the call > > to server_accept_connection is one of those on which pselect waited, > > and should have belonged to the current thread. > > Not if the existing process was unlocked. Then this is a random thread. Then let's fix the case of an unlocked process (which AFAIU is not what happened here). But if the process was locked to a particular thread, as that is the default, then do you agree that this code should be run by that very thread, at least nominally? > >> If that doesn't fix it (or you already had that commit), can you try > >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > > > What will that prove? Those changes are not going away, so trying > > that is just wasting everyone's time and energy. I thought we were > > past that... > > No, we're not past that, I still think those changes are wrong. > Especially because this bug report shows that those changes are indeed > breaking existing code. > > I repeatedly said that those changes would cause new issues to be > reported, and now it is happening. Maybe it doesn't convince you that > the changes need to be reverted, but you should at least be giving it a > little more credence now. This particular breakage is simply because my change was incomplete: it left some processes not locked to their thread, and the solution proposed by the OP, which fixed that blunder, is simpler and has fewer downsides than backing out the process locking to threads. This happens all the time in development, and the conclusion is rarely that the original changes should be backed out, certainly not if there are simpler fixes.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:43:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 10:43:21 2025 Received: from localhost ([127.0.0.1]:35415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utSEC-0002EB-Bl for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:43:21 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55694) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utSE8-0002D0-Ea for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:43:17 -0400 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 1utSDw-0003Cx-Ur; Tue, 02 Sep 2025 10:43:07 -0400 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=TxQEB62ReXN6bVQbv5D5bC6znRbcwwzZmjaYt+/SBQk=; b=M4PaJ2/hSo2U qztZTVXNTfUY31LWLZQSIz1NaG9I2IOFyPlZDJjbmCbJdKzmv8PWzebaEiSrIwp4ENpkBnwjYdNjs qhei3GFkG26Q2TK3/ZraKX3Cz3dff5l7N/E+qE2c52tZu3GJe879KMw41CjAK0ovyQC8znRMB+VED 30sG0XHJFrzCTgEw1ifOBSJpEqFhaLtnkXjGlYQ3uZWCz6Ee5z6h+/fecPfQB7T43J57sS/XPn4t2 RCEqaGc8VPiFf9ZSXNxsBSPjeCTDFucvzVQhUE3rWHYBHrvMtoHw98CmyN6nzxmTVOX6YZvRfgrMa pOqlb2BtT9jvAu5Ann2bBw==; Date: Tue, 02 Sep 2025 17:42:56 +0300 Message-Id: <86wm6glxu7.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ierseh5lzz4.fsf@HIDDEN> (message from Spencer Baugh on Tue, 02 Sep 2025 09:56:47 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <8734950xwv.fsf@HIDDEN> <ierseh5lzz4.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > 79367 <at> debbugs.gnu.org > Date: Tue, 02 Sep 2025 09:56:47 -0400 > > Zhengyi Fu <i@HIDDEN> writes: > > Spencer Baugh <sbaugh@HIDDEN> writes: > >>>> Further debugging through gdb revealed more details: the `thread' > >>>> member of the fd_callback_info entry for the server connection > >>>> references the diff-hl-async thread, which is already exited. > >> > >> This aspect sounds similar to bug#79201. > >> > >> Zhengyi, I assume you're testing with an Emacs built from source. Can > >> you check whether the Emacs you're building includes commit > >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > >> weeks ago? If not, can you pull and test again? > > > > Yes, it includes that commit. > > > >> If that doesn't fix it (or you already had that commit), can you try > >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > > > After reverting those two commits, it worked fine. > > Thanks for testing. > > I believe the right fix is to revert those commits, since they are > already breaking existing code using threads. I object to doing that, for reasons that were already abundantly discussed. An alternative fix was suggested by the OP that is IMO a step in the right direction. IOW, this scenario reveals yet another call to make_process (which sets the process's 'thread' member, something that was always done there) which isn't followed by marking the I/O descriptors with that same thread. So TRT is to add that missing call to set_proc_thread.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:33:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 10:33:23 2025 Received: from localhost ([127.0.0.1]:35276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utS4Y-00014s-Il for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:33:23 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:43235) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utS4T-000143-SV for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:33:19 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <863495lz0d.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Sep 2025 17:17:38 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <863495lz0d.fsf@HIDDEN> Date: Tue, 02 Sep 2025 10:33:12 -0400 Message-ID: <ierplc8ncuv.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=1756823592; bh=k9MUtmnPIR5ICj/I8Xe+qdhOL0yEnADdUZT9WnD46fs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=wEmMTl1WI0PQ5ZwR2L0Ws98cskKU05z6ee2D1ZT1W5j0lhzvwxPtgMkBRdpXRsLJB Yw+DlhgVuANc2hSV83pwFIerfSrI9ZDcLZI8PnbOCalLwCWlrVR5dOos9jj+KUMEvW 69r5wtwNu8zFILsehqGqQok8uuvJPItqY4Jz3nG2nrdPqp1W4NEBRohTqtVD+FzBoa ESLIgdAIvwaPpwJ1YC6i9Oo1UL6dLQPO2tDgpg1Ec9gzaw2u+AnJLj9Sa5KovWwr+t usNFhm6cdQEChTcC2iWd+fmZMq0T4ft39f9M/RCUNtiOzbmizDtQysrouVlNU2tEV6 JrbZpePsLvBXA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: >> From: Spencer Baugh <sbaugh@HIDDEN> >> Cc: Zhengyi Fu <i@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, >> 79367 <at> debbugs.gnu.org >> Date: Tue, 02 Sep 2025 09:08:14 -0400 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> --- a/src/process.c >> >> +++ b/src/process.c >> >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) >> >> /* Client processes for accepted connections are not stopped initially. */ >> >> if (!EQ (p->filter, Qt)) >> >> add_process_read_fd (s); >> >> + set_proc_thread (p, current_thread); >> >> + >> >> if (s > max_desc) >> >> max_desc = s; >> > >> > Thanks. >> > >> > I believe you are right, since server_accept_connection calls >> > make_process to create a new process object, which should by default >> > be locked to the thread which created it. >> > >> > Spencer and Dmitry, do you agree? >> >> No. At worst, the locking of the new connection should match that of >> the existing process. The new connection should not randomly be locked >> to the thread which happened to run wait_reading_process_output. > > But make_process, called by server_accept_connection, already did > this: > > pset_thread (p, Fcurrent_thread ()); > > So if we want to lock this new process to some other thread, we should > fix that part as well to be consistent. True, that's a bug. > And why do you think this thread is a random one? If everything works > as intended, it is the thread which created the existing process, > because the descriptor whose presence in Available triggers the call > to server_accept_connection is one of those on which pselect waited, > and should have belonged to the current thread. Not if the existing process was unlocked. Then this is a random thread. >> >> Further debugging through gdb revealed more details: the `thread' >> >> member of the fd_callback_info entry for the server connection >> >> references the diff-hl-async thread, which is already exited. >> >> This aspect sounds similar to bug#79201. >> >> Zhengyi, I assume you're testing with an Emacs built from source. Can >> you check whether the Emacs you're building includes commit >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple >> weeks ago? If not, can you pull and test again? >> >> If that doesn't fix it (or you already had that commit), can you try >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > What will that prove? Those changes are not going away, so trying > that is just wasting everyone's time and energy. I thought we were > past that... No, we're not past that, I still think those changes are wrong. Especially because this bug report shows that those changes are indeed breaking existing code. I repeatedly said that those changes would cause new issues to be reported, and now it is happening. Maybe it doesn't convince you that the changes need to be reverted, but you should at least be giving it a little more credence now.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 14:18:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 10:18:02 2025 Received: from localhost ([127.0.0.1]:35114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utRph-00081f-RK for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:18:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utRpb-00080u-1d for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 10:17:56 -0400 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 1utRpP-0006MB-Qn; Tue, 02 Sep 2025 10:17:44 -0400 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=7i7nvioY5IhRoyipLEloWwpTkrKZ+tm3UHJcnZsF1uQ=; b=cNF3xDpRAzPk g5slJ48MEJfxIq0mnOfYE/lidQjaJDBo80YubarNgL1IuAPVnyuUTAuGe+xxbzqoPE/PlwXKNlSJ4 yzMG/TxYauMilGjFXEMJetRDiS3BRku7dABHcqER4DS9SQCBDftt7+znhFkDSq8DbL15Xd/4B4bHL sGdRwGKzZMHsG1MiMqGq5XPeS86LIyefx8q0oonHs9jV55t7kJ9++2G6psjEDK5V8OW/4fxBJKZSl 0qEK6wsD+LWoIXVaRXuWoiHAp3NCbB346xlWZNchZiC+86SumHOD+NHbtLFWfzbsa7W/rWupEhUAc RDuiv9m7I71GGo8GoVq0zA==; Date: Tue, 02 Sep 2025 17:17:38 +0300 Message-Id: <863495lz0d.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier1popngsh.fsf@HIDDEN> (message from Spencer Baugh on Tue, 02 Sep 2025 09:08:14 -0400) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: i@HIDDEN, dmitry@HIDDEN, 79367 <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: Zhengyi Fu <i@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, > 79367 <at> debbugs.gnu.org > Date: Tue, 02 Sep 2025 09:08:14 -0400 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> --- a/src/process.c > >> +++ b/src/process.c > >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) > >> /* Client processes for accepted connections are not stopped initially. */ > >> if (!EQ (p->filter, Qt)) > >> add_process_read_fd (s); > >> + set_proc_thread (p, current_thread); > >> + > >> if (s > max_desc) > >> max_desc = s; > > > > Thanks. > > > > I believe you are right, since server_accept_connection calls > > make_process to create a new process object, which should by default > > be locked to the thread which created it. > > > > Spencer and Dmitry, do you agree? > > No. At worst, the locking of the new connection should match that of > the existing process. The new connection should not randomly be locked > to the thread which happened to run wait_reading_process_output. But make_process, called by server_accept_connection, already did this: pset_thread (p, Fcurrent_thread ()); So if we want to lock this new process to some other thread, we should fix that part as well to be consistent. And why do you think this thread is a random one? If everything works as intended, it is the thread which created the existing process, because the descriptor whose presence in Available triggers the call to server_accept_connection is one of those on which pselect waited, and should have belonged to the current thread. If that is not true, then it's a separate problem which should be fixed, perhaps as part of the related discussions. > >> Further debugging through gdb revealed more details: the `thread' > >> member of the fd_callback_info entry for the server connection > >> references the diff-hl-async thread, which is already exited. > > This aspect sounds similar to bug#79201. > > Zhengyi, I assume you're testing with an Emacs built from source. Can > you check whether the Emacs you're building includes commit > 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > weeks ago? If not, can you pull and test again? > > If that doesn't fix it (or you already had that commit), can you try > reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > c93be71e45d4cebeb017c813426228e579e9381d and test again? What will that prove? Those changes are not going away, so trying that is just wasting everyone's time and energy. I thought we were past that...
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:56:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 09:56:58 2025 Received: from localhost ([127.0.0.1]:34883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utRVJ-0005bY-Mv for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:56:58 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46927) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utRVF-0005ah-Se for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:56:54 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Zhengyi Fu <i@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <8734950xwv.fsf@HIDDEN> (Zhengyi Fu's message of "Tue, 02 Sep 2025 21:46:56 +0800") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> <8734950xwv.fsf@HIDDEN> Date: Tue, 02 Sep 2025 09:56:47 -0400 Message-ID: <ierseh5lzz4.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=1756821407; bh=och3m/30ExQmqqIyibwY3oQnJLIySWkR9EioUYTtZos=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=nYKzPdOdVpYqhXCI15liYA5SM5mIzXoW+ZY+9CAxnZeFKPZcXoW1K+TK/XpY4Imbt 88HuNAuhOxbS2c3O2cMdFXv2XqlHTMoFSwqlkZN0BkX8JSCCY2nMUJWGANDJSvsoSv oNW3kWilkEoxdMYjfnDU10NtQAtarFEgn+Yg4uv9PgLxiNjL1QmIaBJJ/tUQnCtB5L vE5TWwwSDeAq3onXBKKzN4BMIXxVZ269LFrICf/nY3xio7XueaxXPa4HP8fZPkDiD7 leVqZqkFJiMIfHqiNd+0lccfLCUXCRx4iaPaWvJjIwe5cjNqLiRQsRO60V9N1BZQ/e MuT1PCu8gP2Bg== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 79367 <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 (---) Zhengyi Fu <i@HIDDEN> writes: > Spencer Baugh <sbaugh@HIDDEN> writes: >>>> Further debugging through gdb revealed more details: the `thread' >>>> member of the fd_callback_info entry for the server connection >>>> references the diff-hl-async thread, which is already exited. >> >> This aspect sounds similar to bug#79201. >> >> Zhengyi, I assume you're testing with an Emacs built from source. Can >> you check whether the Emacs you're building includes commit >> 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple >> weeks ago? If not, can you pull and test again? > > Yes, it includes that commit. > >> If that doesn't fix it (or you already had that commit), can you try >> reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then >> c93be71e45d4cebeb017c813426228e579e9381d and test again? > > After reverting those two commits, it worked fine. Thanks for testing. I believe the right fix is to revert those commits, since they are already breaking existing code using threads.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:47:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 09:47:14 2025 Received: from localhost ([127.0.0.1]:33789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utRLt-0004dE-I6 for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:47:13 -0400 Received: from relay5-d.mail.gandi.net ([2001:4b98:dc4:8::225]:40821) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <i@HIDDEN>) id 1utRLo-0004cQ-4o for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:47:08 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3846D43272; Tue, 2 Sep 2025 13:46:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1; t=1756820821; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B/cyTuy8hu3EhroWJc2FasSP3hIahDWZmPlnE+vTD4g=; b=VxvhzerPvZLf+LUTcbay7CeL/JiGx0ZNpmRoBd33Vwq0WiSYypZfhXl4YWvYY/OIL/XROX ukyxePo96ryQGHp16V1gCUCg9Toy8imQjowXyZQL6Uxi/RseUY2A1dEYmPo+4bjLAn5ext p0dbVsMjGNIQ3yUR6VWbSHHzhc8chFlsqKdQWA57m3vfcWzlLSAcZtzzZhWw2yDTnF9xm+ twlCgg2AUh6iqz+73aGFvZ8mqzoVTgiN5c6X9rMNzP/PLUWPmMEcR2MEHd76Y2Afscx9ef eac5ZVvWu4rFF7EmaruD12w8swAK+PaGft5kGPqgvVh4LDEUCMEYsX2BNfdtzQ== From: Zhengyi Fu <i@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <ier1popngsh.fsf@HIDDEN> References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> <ier1popngsh.fsf@HIDDEN> Date: Tue, 02 Sep 2025 21:46:56 +0800 Message-ID: <8734950xwv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdegvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfitefpfffkpdcuggftfghnshhusghstghrihgsvgenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvvefujghffffkfgggtgesthdtredttdertdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnheptedvueevffejudfgtdejuefgjeejgedtkeetfefftdeggfffteffieeuhfdtgeefnecukfhppeeghedrkedrudekiedruddtvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeeghedrkedrudekiedruddtvddphhgvlhhopegtrghllhhiohhpvgdpmhgrihhlfhhrohhmpehisehfuhiihidrmhgvpdhnsggprhgtphhtthhopeegpdhrtghpthhtohepjeelfeeijeesuggvsggsuhhgshdrghhnuhdrohhrghdprhgtphhtthhopegumhhithhrhiesghhuthhovhdruggvvhdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehssggruhhghhesjhgrnhgvshhtrhgvvghtrdgtohhm X-GND-Sasl: id@HIDDEN X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79367 Cc: Dmitry Gutov <dmitry@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, 79367 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.7 (-) Spencer Baugh <sbaugh@HIDDEN> writes: >> >> Spencer and Dmitry, do you agree? > > No. At worst, the locking of the new connection should match that of > the existing process. The new connection should not randomly be locked > to the thread which happened to run wait_reading_process_output. > >>> Further debugging through gdb revealed more details: the `thread' >>> member of the fd_callback_info entry for the server connection >>> references the diff-hl-async thread, which is already exited. > > This aspect sounds similar to bug#79201. > > Zhengyi, I assume you're testing with an Emacs built from source. Can > you check whether the Emacs you're building includes commit > 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple > weeks ago? If not, can you pull and test again? Yes, it includes that commit. > If that doesn't fix it (or you already had that commit), can you try > reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then > c93be71e45d4cebeb017c813426228e579e9381d and test again? After reverting those two commits, it worked fine.
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 13:08:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 09:08:25 2025 Received: from localhost ([127.0.0.1]:33431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utQkL-0002DG-5o for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:08:25 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:50163) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utQkG-0002Cv-IO for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 09:08:22 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t In-Reply-To: <865xe1m3uu.fsf@HIDDEN> (Eli Zaretskii's message of "Tue, 02 Sep 2025 15:32:57 +0300") References: <xifv7wplc92x7x.fsf@HIDDEN> <865xe1m3uu.fsf@HIDDEN> Date: Tue, 02 Sep 2025 09:08:14 -0400 Message-ID: <ier1popngsh.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=1756818494; bh=oCYIDwKdr/vQrWruQLLGNssPG16Pe+4teGs224A8qNI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=qVNRFf9s/YxVQSfKjspJqaQh8PCpYxWACy4pocRm/aCs2BlEOsca9BfHRhWWXBwCQ t/W8YZFZrmIa/qG1X5Prg6UmZNK4Zxefmvu48XzQG9N007OeJjdbZl98ka28hFsYGk koa4EWOtd5HhEA47bl8JFrnDl1zbPw0/3THYCFSGSoyBy6KvFCHdgFAOCjeA5eSfP6 Etc+UlyeEKmZUzcwvyNERw+onk2ILQ5lrBuyniZkD8FLD1p29ZrZeYhP1UACYKSGF8 932heo8PuBsE1nUHB3bLyXme7jbqYP4p3wZA5E8FmrrbQysqWRBqSL+AcdEdBRb3XU sAvu9oB/xvZhA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: Zhengyi Fu <i@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN>, 79367 <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: >> From: Zhengyi Fu <i@HIDDEN> >> Date: Tue, 02 Sep 2025 14:18:58 +0800 >> >> Hi Emacs maintainers, >> >> I have been suffering from this bug for a few weeks. >> >> I spent a few days finding minimal steps to reproduce the bug: >> >> - Install diff-hl and magit >> - Set `diff-hl-update-async' to t and enable global-diff-hl-mode >> - Enable server-mode >> >> - Open a file in a git repo, make some changes and save it >> - Run `magit-stage-buffer-file' to stage the changes >> - Run `revert-buffer' in the file buffer, and make sure the diff-hl >> fringes are displayed >> - Run `magit-commit-create' >> >> At this moment, a COMMIT_EDITMSG buffer should appear. But actually >> sometimes no buffer appears. >> >> If you run `list-processes', you can see that the git process and the >> server connection are all there, as shown below. >> >> git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit -- >> server -- listen -- -- Main (network server on /run/user/150425139/emacs/server) >> server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server) >> >> >> The commit message buffer will pop up, if you eval >> (set-process-thread (get-process "server <2>") nil) >> >> Further debugging through gdb revealed more details: the `thread' >> member of the fd_callback_info entry for the server connection >> references the diff-hl-async thread, which is already exited. >> >> Simply adding a `set_proc_thread' in `server_accept_connections' like >> the following seems to resolve the issue, but I'm not sure if this is >> the correct fix. >> >> diff --git a/src/process.c b/src/process.c >> index d6efac5479d..326a36716d5 100644 >> --- a/src/process.c >> +++ b/src/process.c >> @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) >> /* Client processes for accepted connections are not stopped initially. */ >> if (!EQ (p->filter, Qt)) >> add_process_read_fd (s); >> + set_proc_thread (p, current_thread); >> + >> if (s > max_desc) >> max_desc = s; > > Thanks. > > I believe you are right, since server_accept_connection calls > make_process to create a new process object, which should by default > be locked to the thread which created it. > > Spencer and Dmitry, do you agree? No. At worst, the locking of the new connection should match that of the existing process. The new connection should not randomly be locked to the thread which happened to run wait_reading_process_output. >> Further debugging through gdb revealed more details: the `thread' >> member of the fd_callback_info entry for the server connection >> references the diff-hl-async thread, which is already exited. This aspect sounds similar to bug#79201. Zhengyi, I assume you're testing with an Emacs built from source. Can you check whether the Emacs you're building includes commit 37325ed5a9c7f62c35b368d9530496ed31404940, which was pushed just a couple weeks ago? If not, can you pull and test again? If that doesn't fix it (or you already had that commit), can you try reverting commits 034d755f2f21088b97fdb0a34d846c39fcdbf46d then c93be71e45d4cebeb017c813426228e579e9381d and test again?
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.Received: (at 79367) by debbugs.gnu.org; 2 Sep 2025 12:33:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 08:33:54 2025 Received: from localhost ([127.0.0.1]:32970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utQCw-000734-1L for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 08:33:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52850) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1utQCp-00071g-6g for 79367 <at> debbugs.gnu.org; Tue, 02 Sep 2025 08:33:48 -0400 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 1utQCc-0008Hb-Iz; Tue, 02 Sep 2025 08:33:34 -0400 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=1ZIs1HJe88MQz2NjtSDsduDQ4t0hWUsLq8rVUOw/s3c=; b=LactVXqKRuWs 35XdhJGRKrjMm+9QNlIN8E74lfTzlCXDVy9HIUFaJK1n0inYzCHHVHZHcYYvZbOxuKkCbF8Rs4JOh jjcXySg0pv76L1NgTD0M/9PFneJNZjrjnEwd9T/4vGoSfBi/v1Xp7GP5pNy6Oj4vqv7itd9jEq3YL Jf/HR3kjntcOepHBHCoudp7SIWZPzBLHWzyqGGhzKFGMJtDba/aTcRFoR2VNZ9B4ulp4nxerXSaZU UOxLHI4tUh9Us82NP/5MwAvT7ZZdq6nZYiL3u8UWBlGgkBdIyiLwZDeGVpfYOAuo6m1kQVLgytPo6 ZoGTJVi/Sq1nEr9qZMHIHQ==; Date: Tue, 02 Sep 2025 15:32:57 +0300 Message-Id: <865xe1m3uu.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Zhengyi Fu <i@HIDDEN>, Spencer Baugh <sbaugh@HIDDEN>, Dmitry Gutov <dmitry@HIDDEN> In-Reply-To: <xifv7wplc92x7x.fsf@HIDDEN> (message from Zhengyi Fu on Tue, 02 Sep 2025 14:18:58 +0800) Subject: Re: bug#79367: 31.0.50; magit-commit sometimes doesn't work if diff-hl-update-async is t References: <xifv7wplc92x7x.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79367 Cc: 79367 <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: Zhengyi Fu <i@HIDDEN> > Date: Tue, 02 Sep 2025 14:18:58 +0800 > > Hi Emacs maintainers, > > I have been suffering from this bug for a few weeks. > > I spent a few days finding minimal steps to reproduce the bug: > > - Install diff-hl and magit > - Set `diff-hl-update-async' to t and enable global-diff-hl-mode > - Enable server-mode > > - Open a file in a git repo, make some changes and save it > - Run `magit-stage-buffer-file' to stage the changes > - Run `revert-buffer' in the file buffer, and make sure the diff-hl > fringes are displayed > - Run `magit-commit-create' > > At this moment, a COMMIT_EDITMSG buffer should appear. But actually > sometimes no buffer appears. > > If you run `list-processes', you can see that the git process and the > server connection are all there, as shown below. > > git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit -- > server -- listen -- -- Main (network server on /run/user/150425139/emacs/server) > server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server) > > > The commit message buffer will pop up, if you eval > (set-process-thread (get-process "server <2>") nil) > > Further debugging through gdb revealed more details: the `thread' > member of the fd_callback_info entry for the server connection > references the diff-hl-async thread, which is already exited. > > Simply adding a `set_proc_thread' in `server_accept_connections' like > the following seems to resolve the issue, but I'm not sure if this is > the correct fix. > > diff --git a/src/process.c b/src/process.c > index d6efac5479d..326a36716d5 100644 > --- a/src/process.c > +++ b/src/process.c > @@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel) > /* Client processes for accepted connections are not stopped initially. */ > if (!EQ (p->filter, Qt)) > add_process_read_fd (s); > + set_proc_thread (p, current_thread); > + > if (s > max_desc) > max_desc = s; Thanks. I believe you are right, since server_accept_connection calls make_process to create a new process object, which should by default be locked to the thread which created it. Spencer and Dmitry, do you agree?
bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 2 Sep 2025 06:20:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Sep 02 02:20:33 2025
Received: from localhost ([127.0.0.1]:59510 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1utKNZ-00073G-FM
for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 02:20:33 -0400
Received: from lists.gnu.org ([2001:470:142::17]:60216)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <i@HIDDEN>) id 1utKNS-0006wy-U6
for submit <at> debbugs.gnu.org; Tue, 02 Sep 2025 02:20:27 -0400
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 <i@HIDDEN>) id 1utKMp-0004Zj-GM
for bug-gnu-emacs@HIDDEN; Tue, 02 Sep 2025 02:19:54 -0400
Received: from relay1-d.mail.gandi.net ([217.70.183.193])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <i@HIDDEN>) id 1utKMf-0005ax-KJ
for bug-gnu-emacs@HIDDEN; Tue, 02 Sep 2025 02:19:39 -0400
Received: by mail.gandi.net (Postfix) with ESMTPSA id 7641543A8A
for <bug-gnu-emacs@HIDDEN>; Tue, 2 Sep 2025 06:19:26 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fuzy.me; s=gm1;
t=1756793968;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type;
bh=MtdTz2bSu+ZXnp/xHE5etOqHiaw9q+43Y3DRzbyGfH4=;
b=MRKfOVi0/VriuJyG3kpOAQtP+7uSmCefSeQkpY+cCLcJCqm7RW1he3OvVJHloX/QMWA1Bb
o29VIhxa/uNB5uTRJ1OB7wPRZa/6DdJd0ZrFQxbK7AAlaFbe83IUZbb4OAwEXrZyNnJy3E
cNpuFeplRbtljuPJ8F3mbOF9S47WcCL5Id/bXCJy2alWJUjsgpSAR8OPnF2PlHO9GmbQad
Qvr5pfnWrHmnCwMqYTvqFHgOlReu1Zqosv918XIemewjWdAQ9GYbfKTOGiZ1piiGXalLIP
xIF1Op9AzPRPfhA2V+YLeXOcjWKOfp+lW3PfHFavNZStRYX6G3/1ORVdUWTWQA==
From: Zhengyi Fu <i@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; magit-commit sometimes doesn't work if
diff-hl-update-async is t
X-Debbugs-Cc:
Date: Tue, 02 Sep 2025 14:18:58 +0800
Message-ID: <xifv7wplc92x7x.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-GND-State: clean
X-GND-Score: 0
X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdefgdduleegvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecunecujfgurhephffvufffkfggtgesthdtredttddttdenucfhrhhomhepkghhvghnghihihcuhfhuuceoihesfhhuiiihrdhmvgeqnecuggftrfgrthhtvghrnhepueefveekueeuueekkeegjeekveefvdetffetuefhffdtheelgfeiteekvddtleejnecuffhomhgrihhnpehhphhitghorhhprdhnvghtnecukfhppeduledvrdehiedrleelrdduvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduledvrdehiedrleelrdduvddphhgvlhhopehjrghmvghsqdhfuhdquhgsuhhnthhuvdegtdegpdhmrghilhhfrhhomhepihesfhhuiiihrdhmvgdpnhgspghrtghpthhtohepuddprhgtphhtthhopegsuhhgqdhgnhhuqdgvmhgrtghssehgnhhurdhorhhg
X-GND-Sasl: id@HIDDEN
Received-SPF: pass client-ip=217.70.183.193; envelope-from=i@HIDDEN;
helo=relay1-d.mail.gandi.net
X-Spam_score_int: -23
X-Spam_score: -2.4
X-Spam_bar: --
X-Spam_report: (-2.4 / 5.0 requ) BAYES_00=-1.9, DKIM_INVALID=0.1,
DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=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.7 (/)
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.3 (/)
Hi Emacs maintainers,
I have been suffering from this bug for a few weeks.
I spent a few days finding minimal steps to reproduce the bug:
- Install diff-hl and magit
- Set `diff-hl-update-async' to t and enable global-diff-hl-mode
- Enable server-mode
- Open a file in a git repo, make some changes and save it
- Run `magit-stage-buffer-file' to stage the changes
- Run `revert-buffer' in the file buffer, and make sure the diff-hl
fringes are displayed
- Run `magit-commit-create'
At this moment, a COMMIT_EDITMSG buffer should appear. But actually
sometimes no buffer appears.
If you run `list-processes', you can see that the git process and the
server connection are all there, as shown below.
git 542014 run magit-process: emacs_test /dev/pts/1 Main git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false -c diff.noPrefix=false commit --
server -- listen -- -- Main (network server on /run/user/150425139/emacs/server)
server <2> -- open -- -- Main (network connection to t:/run/user/150425139/emacs/server)
The commit message buffer will pop up, if you eval
(set-process-thread (get-process "server <2>") nil)
Further debugging through gdb revealed more details: the `thread'
member of the fd_callback_info entry for the server connection
references the diff-hl-async thread, which is already exited.
Simply adding a `set_proc_thread' in `server_accept_connections' like
the following seems to resolve the issue, but I'm not sure if this is
the correct fix.
diff --git a/src/process.c b/src/process.c
index d6efac5479d..326a36716d5 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5115,6 +5115,8 @@ server_accept_connection (Lisp_Object server, int channel)
/* Client processes for accepted connections are not stopped initially. */
if (!EQ (p->filter, Qt))
add_process_read_fd (s);
+ set_proc_thread (p, current_thread);
+
if (s > max_desc)
max_desc = s;
In GNU Emacs 31.0.50 (build 6, x86_64-pc-linux-gnu, GTK+ Version
3.24.41) of 2025-09-02 built on james-fu-ubuntu2404
Repository revision: b953dc679c53d8ae26770762bcb2601389146768
Repository branch: heads/master
Windowing system distributor 'Microsoft Corporation', version 11.0.12010000
System Description: Ubuntu 24.04.3 LTS
Configured using:
'configure --without-all --with-threads --enable-checking 'CFLAGS=-O1
-ggdb3 -pipe''
Configured features:
GLIB GMP PDUMPER SECCOMP THREADS X11 XIM XINERAMA XRANDR GTK3
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
Major mode: Fundamental
Minor modes in effect:
global-git-commit-mode: t
magit-auto-revert-mode: t
auto-revert-mode: t
server-mode: t
global-diff-hl-mode: t
diff-hl-mode: t
straight-use-package-mode: t
straight-package-neutering-mode: t
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-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:
/var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/transient/transient hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/transient
/var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/seq/seq hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/emacs-lisp/seq
/var/lib/domain_home/auth.hpicorp.net/fujames/.config/emacs/straight/build/compat/compat hides /var/lib/domain_home/auth.hpicorp.net/fujames/src/emacs_test/lisp/emacs-lisp/compat
Features:
(shadow sort mail-extr emacsbug lisp-mnt bug-reference thingatpt
help-fns radix-tree cl-print debug backtrace find-func
display-line-numbers face-remap magit-submodule magit-blame magit-stash
magit-reflog magit-bisect magit-push magit-pull magit-fetch magit-clone
magit-remote magit-commit magit-sequence magit-notes magit-worktree
magit-tag magit-merge magit-branch magit-reset magit-files magit-refs
magit-status magit package url-handlers magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode diff
git-commit magit-core magit-autorevert autorevert filenotify
magit-margin magit-transient magit-process with-editor shell pcomplete
comint ansi-osc ansi-color magit-mode transient pp edmacro kmacro
browse-url xdg url url-proxy url-privacy url-expand url-methods
url-history url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source icons json map url-vars benchmark magit-git magit-base
magit-section format-spec cursor-sensor crm llama eieio byte-opt
eieio-core cond-let compat server vc-git files-x diff-hl log-view
log-edit message sendmail 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 mm-decode mm-bodies mm-encode
mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr
mailabbrev mail-utils gmm-utils mailheader ring add-log pcvs-util vc-dir
ewoc vc vc-dispatcher diff-mode track-changes easy-mmode magit-autoloads
pcase with-editor-autoloads transient-autoloads magit-section-autoloads
llama-autoloads cond-let-autoloads compat-autoloads info seq-autoloads
diff-hl-autoloads finder-inf straight-autoloads cl-seq cl-extra
help-mode straight subr-x cl-macs gv cl-loaddefs cl-lib bytecomp
byte-compile 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 dynamic-setting gtk x-toolkit x multi-tty move-toolbar
make-network-process tty-child-frames emacs)
Memory information:
((conses 16 161628 25408) (symbols 48 16281 0) (strings 32 52533 3112)
(string-bytes 1 1564345) (vectors 16 32763)
(vector-slots 8 308800 12722) (floats 8 75 448) (intervals 56 559 0)
(buffers 984 21))
Zhengyi Fu <i@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79367; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.