Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 15:14:51 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 11:14:51 2025 Received: from localhost ([127.0.0.1]:48198 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uQ67H-0000LZ-GH for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 11:14:51 -0400 Received: from fhigh-a4-smtp.messagingengine.com ([103.168.172.155]:48989) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steven@HIDDEN>) id 1uQ67F-0000LI-0n for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 11:14:49 -0400 Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 8973911400F3; Fri, 13 Jun 2025 11:14:43 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-10.internal (MEProxy); Fri, 13 Jun 2025 11:14:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com; 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=1749827683; x=1749914083; bh=Gee0h8IYCkvUEA535JMAlirqEcK0p6sY fv/NmP0f5L0=; b=ka2Nn3D+ZnquIaLtde+tn1D0oHb/j1xcKUSLKG0tcO2Ltxxr nFRUEhdVYQEWXLl8uYqBqmzPykqvEnYAZohc3/ra9RdclVtlfowGVxLodWB27gCj /YRkiB3kNJRdPNNmYmapNXuf/diWdH0SQwLQVc0BpTtYmRVtl4KkFzMPXhnR3aax n5BidPRFLQRUe4MAYSj4szEbHOXBJzyByu0CMQm+YrojLLmmIZgXuLbYO6zew9r6 +R5aw9uKsRDlFuyr4LV5j78HFw/yGZq4qVg8z+R5q+QuKZV3SazF3DIHd6jx9jYa ZzbTrGSjBTZaQ5mDcNT3qh/VUo3uFwf7MknGug== 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=1749827683; x= 1749914083; bh=Gee0h8IYCkvUEA535JMAlirqEcK0p6sYfv/NmP0f5L0=; b=M nA0ddv8yxG8WCwojl79T8xvdhcr8JMOJzBMoIGzBtR7Nw+gRETcyTTeSAaWQF0Fb 96CTTv8sgWr+dopgxul85WO/mUar5uSRs07TmaEo6qTdkWN5SQ2ldkegMtZZS4IL Apms/935lhBaub/oZ2DrOUzrE7dOHGTTOkaK1AsHe3eOZdXdtyU/9fOt7PulmKsu 0qWdPrDMswHkrO2bLznRGrPuHEFHxS1Qp05RXzwbXGE3rH935E4BljzeoUuyL2Xd /RAfifhncbsP2Di+0tWv4o+eWwvF5Mo+BQLPNmBKv+8GrbOTsS8cLu2HyrJRsUAg MAH7SdA560q0I0mSHUl1Q== X-ME-Sender: <xms:Y0BMaO5UfOV6zBk183K8X6Wek4AUMk0wOeaC93PTaNt-ozjez-U1MA> <xme:Y0BMaH4ZnGHBiqUGkN8Hzoa4mxblT0i70SIU6SxK9t3I-5dK9QwSlxk2OujiCu0DK MswaYRkPj69-wTQ904> X-ME-Received: <xmr:Y0BMaNdm5onDKMIO7mUql6ccQaPDBRZOq_A3LGEFpjk1uHHx9COnEQCrv9yEupBuQiEeHTppLVzTTku38USyoW8ZFmPc080> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddukedvkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgfgsehtqhertddttdej necuhfhrohhmpefuthgvvhgvnhcutehllhgvnhcuoehsthgvvhgvnhesshhtvggsrghlih gvnhdrtghomheqnecuggftrfgrthhtvghrnhepudevlefgtdekheekgffhtdegheduhfeg tdfgffefteetgfetkeeivddthefhkeetnecuffhomhgrihhnpehgnhhurdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtvghvvghn sehsthgvsggrlhhivghnrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmth hpohhuthdprhgtphhtthhopehrphhluhhimhesghhmrghilhdrtghomhdprhgtphhtthho pegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejkeejjeefseguvggssghughhsrd hgnhhurdhorhhgpdhrtghpthhtoheplhgrrhhsihesghhnuhhsrdhorhhg X-ME-Proxy: <xmx:Y0BMaLJfljzk1L9bB4_npvl32fleSclJWH-w4iNm5OwbMbeCB-XPuQ> <xmx:Y0BMaCJvXLaFijO9wgOnvNs8iabehR2aO1lkJ1ABt806XmkW0uWTtg> <xmx:Y0BMaMx5ciFYYxwhcjhWrPOpUt0ePqcjzPmHFRbR80EAXxg2t6SQXw> <xmx:Y0BMaGK12LlsKjEmhwgBUDT7uQONCcVQ1r6XwF1PSm0UL3D1tbi4Aw> <xmx:Y0BMaLpKhoUIK7RcsU1_KtDCjuaSjPG6g49Qj0FR7R6uKJOZPWZaBxRx> Feedback-ID: ie8a146a7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Jun 2025 11:14:42 -0400 (EDT) From: Steven Allen <steven@HIDDEN> To: Robert Pluim <rpluim@HIDDEN> Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections In-Reply-To: <87zfeb8z72.fsf@HIDDEN> References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> <87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN> <87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN> <87bjqs9fxc.fsf@HIDDEN> <86jz5fex3r.fsf@HIDDEN> <874iwjam37.fsf@HIDDEN> <87bjqrhezw.fsf@HIDDEN> <87zfeb8z72.fsf@HIDDEN> Date: Fri, 13 Jun 2025 08:14:41 -0700 Message-ID: <875xgzhdwe.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@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 (-) Robert Pluim <rpluim@HIDDEN> writes: >>>>>> On Fri, 13 Jun 2025 07:50:59 -0700, Steven Allen <steven@HIDDEN= om> said: > > Steven> I think this patch will cause us to the final drain loop when= waiting on > Steven> a single connection. It's probably fine, but I assume this dr= ain loop > Steven> existed for a reason? > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/p= rocess.c?h=3Dbec823b107ef7d3b51b8e430ccab82c81bd63d24#n5525 > > It will, but we=CA=BCll already have read from the process at line 5972 or > thereabouts. > > Since I can=CA=BCt definitively say it won=CA=BCt break anything, we shou= ld go > with the minimal patch, ie yours. Your approach is correct, I think. It just may be less performant as the user will now need to accept output twice when we could have just "finished the job" the first time around.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 14:59:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:59:39 2025
Received: from localhost ([127.0.0.1]:47779 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uQ5sZ-0007Vk-36
for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:59:39 -0400
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:59857)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1uQ5sW-0007VT-RK
for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:59:37 -0400
Received: by mail-wm1-x334.google.com with SMTP id
5b1f17b1804b1-450ce671a08so13960025e9.3
for <78773 <at> debbugs.gnu.org>; Fri, 13 Jun 2025 07:59:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1749826771; x=1750431571; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=WlR6410Qbghbsx7GOU4ekNOt6WMmI3dB6AaCg9Mj9Bk=;
b=J/+n5HOn3QTypKlYM5oGVmdxE6uMQMhKtrnG8WkHIcbeoRy50VprM/AeuQiqAZAV78
Q+YUS9j3K36sVbB1NDZqxG4Ry92YbPeHeCQdoFhpcBVbxizNNZAzAwLA6CDZDWMivUei
qdEnbHyxObSh4/dft5hOvV3Yw8Mdjx4q33YVamt1lEvV7+XDg9JLlUh8pYfhtFedsY3N
g8VOpME/E6MNbW08di6eicBl4e1In06ZzubCuQKJdM1ZSQzcacFEvsUxFzldMYWzQb2x
LnsChBOxBvyI11bym1aVPWAvgdsGdY8Cgj+7tbwK6HyF41DapAsMSUQciikaOiEffz1B
yOpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1749826771; x=1750431571;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=WlR6410Qbghbsx7GOU4ekNOt6WMmI3dB6AaCg9Mj9Bk=;
b=MizwbR+hdtC+Gu0cSjTrWcoZdpkuDVy5uZClCrSBnifP6PZ1q6FOMUUDTH0KAZjo9R
O8Fs/9enLMdGvs6dAjCgoif2fRu373vQn2Sgca3EB5s1t4CzPloQHPNSGOSgXwdwcc4m
/xeVGnWv/cot5ZMOi7JbSaweaSWoH3l9gBDKP6bHAMiL2xE3SYkUXp2+TcnlMATDA/vD
iiLlKafX9UM5kRzPTTpfkRD3UqK7O8FsDuFdY4HCRweOKW1AWCIvnz/8nR8M5kqJL8MG
H+1tzBxxBnEnwhcZTMoqT/d989aI/NYmnLTcQoh6s2FclkUGIQG3e8B/dUWJvYEKrtFH
AqNA==
X-Forwarded-Encrypted: i=1;
AJvYcCXYRohkzW0Ss03/VM7bgBQ5aEnKn18gXSki0URMPMwhUAP+jj3pl1wRRZKVRTXBrj8T7OAqKA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwWGZk54olLLBseF3mMusGzObMuTDlsWfT+noysNYkAEgHFMITx
C8qcxSsquySGyZm7ixpVmZz0iEQbHBjQKu/GB2SgftR+nQc3OJHfdpgeIN2kSwTs
X-Gm-Gg: ASbGncsu06rdObMfZlOSVP+L9EC0js8Mvl7eUfTSC+pbVGZTj6Z8h5CS/aGh0XXg24j
k2/hiMugwtr7w9xpujQHRIPzOJynPkSMkXiGHmh03f7p03Ln+pbbq4HOdnOuZt+l9DRVy13NSqa
nY7qKkUzNqI2xIiylO/F4oz+vWXZqxXIAec6lYbico5W05OmpYUIdkDFKu9M6qtadX6YTqgTkAb
Mqu8JL4B54J5ev2xmMyhEXmUEYZr184ecC42KNbrtZGJ/dp3MzBumVgBYCKCLHBZ22H4Pwr9vsd
M+NalfqgN9ho9eni3RX0ApzpGBa/TYAw8zzTQ0y9PE51DqxeVg==
X-Google-Smtp-Source: AGHT+IEUPylrGlUjs+p/QAywlAtzx0NMWJeoLDOqPpYaEX+91lINIappnT+Qpcpqsd1u1GjKXOZMNA==
X-Received: by 2002:a05:600c:4f09:b0:43d:8ea:8d7a with SMTP id
5b1f17b1804b1-45334af5c89mr30044275e9.28.1749826770398;
Fri, 13 Jun 2025 07:59:30 -0700 (PDT)
Received: from rltb ([2a01:e0a:3f3:fb51:df39:e830:abf3:ba4f])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-3a568a7fa9dsm2584708f8f.44.2025.06.13.07.59.29
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 13 Jun 2025 07:59:29 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: Steven Allen <steven@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <87bjqrhezw.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN>
<87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN>
<87bjqs9fxc.fsf@HIDDEN> <86jz5fex3r.fsf@HIDDEN>
<874iwjam37.fsf@HIDDEN> <87bjqrhezw.fsf@HIDDEN>
Date: Fri, 13 Jun 2025 16:59:29 +0200
Message-ID: <87zfeb8z72.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
>>>>> On Fri, 13 Jun 2025 07:50:59 -0700, Steven Allen <steven@HIDDEN=
m> said:
Steven> I think this patch will cause us to the final drain loop when w=
aiting on
Steven> a single connection. It's probably fine, but I assume this drai=
n loop
Steven> existed for a reason?
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3Dbec823b107ef7d3b51b8e430ccab82c81bd63d24#n5525
It will, but we=CA=BCll already have read from the process at line 5972 or
thereabouts.
Since I can=CA=BCt definitively say it won=CA=BCt break anything, we should=
go
with the minimal patch, ie yours.
Robert
--=20
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 14:51:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:51:09 2025
Received: from localhost ([127.0.0.1]:47549 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uQ5kL-0006tE-3h
for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:51:09 -0400
Received: from fout-a1-smtp.messagingengine.com ([103.168.172.144]:35637)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steven@HIDDEN>)
id 1uQ5kI-0006sh-ND
for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:51:07 -0400
Received: from phl-compute-01.internal (phl-compute-01.phl.internal
[10.202.2.41])
by mailfout.phl.internal (Postfix) with ESMTP id 1764B13806AB;
Fri, 13 Jun 2025 10:51:01 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
by phl-compute-01.internal (MEProxy); Fri, 13 Jun 2025 10:51:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com;
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=1749826261; x=1749912661; bh=88FqpJjfKy6u8R1+Z8ZkPkp4ab4l420q
2n59gxff5Tk=; b=L/37h56QFMWZoHkZ0sZYYVKKJWUsxbnIBuZEZKtJAoGqrcMD
8GfXJBWo1JxoINdlw/0sxGPBy0zFyxW3Bwwps1U4J9PnKau+RHyo7U6phdTghoJ1
UHqSeLrAcROYfv9xYKnChfHBd/cqDyscZKRVbN/RvIfNAA0r1RVR7IboK0k+NVdL
4bCFtA6PkXpO0Bl4yDhPxGRLurGO1h6DEhcr9/41MUUiN8r1BDL1YqsxpbFzTzd0
9F7vt1VdUmlvmX2pJlE9HegcrsSITl10979b+yiEEkZrTSCrSaa+zHn+UcpqBYH7
tUi8B/Q05L+FtD7O8RQ9GcsfaBA/+UA/xjQkMw==
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=1749826261; x=
1749912661; bh=88FqpJjfKy6u8R1+Z8ZkPkp4ab4l420q2n59gxff5Tk=; b=B
7G+9YYeUyAzcvWMLwGET1Q3cbegou8N2Hr+8gsguofys4FDxhadD6m00mzJjU0D7
iodc5QiaI2/qDbAzp/vi8W9RnkCRPIhDEA04NkfWepUX33qljyRuCB0E9VjSVf+t
ccWcwgYui8akc8jYeHTQwQyZrtUqUgKhZ0VsjJwm2tkLKHsSQgVr8jQtzdvGhEkc
qhTkKNHwQdGDfbLRKGPuXecA9c1DHz6r2zv8Vq789PB4+jknybI+NBnIy7Wz4St8
NspApHm3F67o42zdNDqROXuXZitJfSK+LSJcGmdBL1vVTqtdFjVkIfZsqzt71gKC
20UpFnnCPhGXZodyQHQqw==
X-ME-Sender: <xms:1DpMaMfN6kAGbmvyAhTEjaUeuwmmj-evjbx6Zcai-u5K1VyfYeLVJQ>
<xme:1DpMaOODRCY-WyRnHQ2xWM3DlkWFq5Z_OQWaLeUp2BM_0mJICeNKtP8c-Ay8rsxVx
tB2D8TnQUsIlCQhSlU>
X-ME-Received: <xmr:1DpMaNhxTkDSdTnB2o4vQQzdWH5xUfY3A9OisEw2AhtZLKgnpoO4f6EGqr78w2-wR8DCiUgmAIfA7HwlsofZNB7XAtaKPZw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddukedvfecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgfgsehtqhertddttdej
necuhfhrohhmpefuthgvvhgvnhcutehllhgvnhcuoehsthgvvhgvnhesshhtvggsrghlih
gvnhdrtghomheqnecuggftrfgrthhtvghrnhepudevlefgtdekheekgffhtdegheduhfeg
tdfgffefteetgfetkeeivddthefhkeetnecuffhomhgrihhnpehgnhhurdhorhhgnecuve
hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtvghvvghn
sehsthgvsggrlhhivghnrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmth
hpohhuthdprhgtphhtthhopehrphhluhhimhesghhmrghilhdrtghomhdprhgtphhtthho
pegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopeejkeejjeefseguvggssghughhsrd
hgnhhurdhorhhgpdhrtghpthhtoheplhgrrhhsihesghhnuhhsrdhorhhg
X-ME-Proxy: <xmx:1DpMaB_1sWM0F71JcxHWPEF3qDBW6-EBKc6QNI_jxli4NH7pnHNFWw>
<xmx:1DpMaIv81mtR2XsSjKvOuaEMFlOFn6osjHBiOpymlL3vvQkxhQhpCw>
<xmx:1DpMaIEFeexSkp8uTQ9qgvH3RiYAZrTcVxVHjNp2MZ9DRvJp8zKbLQ>
<xmx:1DpMaHPPAs4On2dxRGax5ayhrDF9zJQnuMturKtym8azfrk2Fk0pGA>
<xmx:1TpMaNPs-ftwMdbeDENDeFiYBWU7tAuGrcufxADamPH_mxw_kSGTDwsm>
Feedback-ID: ie8a146a7:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri,
13 Jun 2025 10:51:00 -0400 (EDT)
From: Steven Allen <steven@HIDDEN>
To: Robert Pluim <rpluim@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <874iwjam37.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN>
<87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN>
<87bjqs9fxc.fsf@HIDDEN> <86jz5fex3r.fsf@HIDDEN>
<874iwjam37.fsf@HIDDEN>
Date: Fri, 13 Jun 2025 07:50:59 -0700
Message-ID: <87bjqrhezw.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, larsi@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 (-)
Robert Pluim <rpluim@HIDDEN> writes:
>>>>>> On Fri, 13 Jun 2025 13:48:08 +0300, Eli Zaretskii <eliz@HIDDEN> sai=
d:
>
> >> I=CA=BCm wondering why we=CA=BCre setting the timeout to zero and =
calling
> >> `pselect' again, which means recomputing the wait set again, if I
> >> haven=CA=BCt gotten lost in the twisty maze of if=CA=BCs and globa=
l variables
> >> =F0=9F=98=80. We=CA=BCve got input, why can=CA=BCt we just `break'=
? There might be some
> >> work we don=CA=BCt do, but that will get done the next time
> >> `wait_reading_process_output' is called.
>
> Eli> Try looking at the Git history of this code, maybe it will tell =
you
> Eli> how this code evolved, and bring up past discussions and bug rep=
orts
> Eli> which caused us to make the code as it is today.
>
> Yes, it=CA=BCs gnarly. I think the following would be ok, and it passes t=
he
> test case for Bug#20978.
>
> But I can=CA=BCt detect any difference in Steven=CA=BCs test case, so may=
be we
> let sleeping pselect=CA=BCs lie.
I think this patch will cause us to the final drain loop when waiting on
a single connection. It's probably fine, but I assume this drain loop
existed for a reason?
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=3Db=
ec823b107ef7d3b51b8e430ccab82c81bd63d24#n5525
> Robert
> --=20
> diff --git a/src/process.c b/src/process.c
> index e61ec425f7e..0119330f7fe 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5934,6 +5934,7 @@ wait_reading_process_output (intmax_t time_limit, i=
nt nsecs, int read_kbd,
> channel_start
> =3D process_prioritize_lower_fds ? 0 : last_read_channel + 1;
>=20=20
> + bool break_now =3D false;
> for (channel =3D channel_start, wrapped =3D false;
> !wrapped || (channel < channel_start && channel <=3D max_desc);
> channel++)
> @@ -5975,8 +5976,11 @@ wait_reading_process_output (intmax_t time_limit, =
int nsecs, int read_kbd,
> if (nread > 0)
> {
> /* Vacuum up any leftovers without waiting. */
> - if (wait_proc =3D=3D XPROCESS (proc))
> - wait =3D MINIMUM;
> + if (!wait_proc || wait_proc =3D=3D XPROCESS (proc))
> + {
> + wait =3D MINIMUM;
> + break_now =3D true;
> + }
> /* Since read_process_output can run a filter,
> which can call accept-process-output,
> don't try to read from any other processes
> @@ -6119,6 +6123,8 @@ wait_reading_process_output (intmax_t time_limit, i=
nt nsecs, int read_kbd,
> }
> }
> } /* End for each file descriptor. */
> + if (break_now) /* Don't rerun select. */
> + break;
> } /* End while exit conditions not met. */
>=20=20
> unbind_to (count, Qnil);
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 14:45:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 10:45:37 2025 Received: from localhost ([127.0.0.1]:47475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uQ5ez-0006YK-1v for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:45:37 -0400 Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154]:47049) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steven@HIDDEN>) id 1uQ5ev-0006Y4-J2 for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 10:45:34 -0400 Received: from phl-compute-09.internal (phl-compute-09.phl.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id 03C7A1140163; Fri, 13 Jun 2025 10:45:28 -0400 (EDT) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-09.internal (MEProxy); Fri, 13 Jun 2025 10:45:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com; h=cc:cc: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=1749825927; x= 1749912327; bh=wIBHhEdoi+Av/lYNU+MRQTNnMnqFJ4IqF+/gtozwJ0Q=; b=L ce6LkgNfogdac+rF5cRwR78MJhKKJdI1Lhy2pnGziLSBwTIFigK3vby+ahL44w5+ qYx6Dm60oDuzVmFvYrqjNoLsIOV4tFhlYW9t/vPXeIuYV5cU/wavUv8Bj9hZQaJA k5MwsyaRPGytO1RWgVyAYyQ2tEhjwgB6YTyIGgv2cWGQaIlZ9+jVaZd+H0Degt3+ vcIUXCL/u4N4JzYma7Tuvo2ac40C704N/AdZ6RzgcOOKTh+kXaknrW4krpALRdnZ qccCW5cgxKJaOuJgg5ezj4uF0eO/xMnvf32ofWGWHF6NiNb1ol9XbHl6kBEvcYo5 v8YKJWurOZ4b8MCq2iGhA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= 1749825927; x=1749912327; bh=wIBHhEdoi+Av/lYNU+MRQTNnMnqFJ4IqF+/ gtozwJ0Q=; b=mEwCLQVnkjRhmcLjEUZ7itTgDhqCBkEPNNQ9zK6NsN5KOiszO8a LRDLct9lpijbMQlk6m/LuwdJJnZtYq/IsQPB1Dmlbn71DDlsN0kSAbhvDlRA60re tu8Uo7/+za3CkIWQSiHhjOy5Ir4rZsIR/71NGXVdfz28RJ3I1sAUBPJoUMgL6x9u QGYKA9sBIU2kjREFz4m2U0GBkvkJvOZfkCjYjtFTTXV09z3dUX1UFJhcwYtxFhIH 4tJPg9sn5PWomq/ScIS3RFGZ3OVBT1au9DLlIL+0A7MeWEAhpSicUWvM7zZVE/xq 4G+tC3klvLoxmgOsueLc3uy617oUjeZHY7Q== X-ME-Sender: <xms:hzlMaGju874aX898SksfKid3Tg6MrWGxiMVql9-zULkZ-mEQ82V42Q> <xme:hzlMaHAO5LVUtZPLlsZK8K0SqynDEPz5xDp7pB_0ZKRPyDYYuHanezoorR3xWDk2D oCEGx-IwoDvO4t47Ac> X-ME-Received: <xmr:hzlMaOEds73FYWdvCC3e_3WkECnpcEXNuwBHakj5Tgl9WhLZD6LMlLS2WvrKSizfqS2EMRLZ864W0mKh5b8RBGQ0G2vzx2k> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddukedvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesthdtredttddttden ucfhrhhomhepufhtvghvvghnucetlhhlvghnuceoshhtvghvvghnsehsthgvsggrlhhivg hnrdgtohhmqeenucggtffrrghtthgvrhhnpeejffefuddvieefgeevkeeggfelhefhffeg leetffetuedttefggeffheeufeektdenucffohhmrghinhepghhnuhdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgvvhgvnhes shhtvggsrghlihgvnhdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtoheprhhplhhu ihhmsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeekjeejfeesuggvsggsuhhgshdrgh hnuhdrohhrghdprhgtphhtthhopehlrghrshhisehgnhhushdrohhrgh X-ME-Proxy: <xmx:hzlMaPRKa6BAXytMMP3-QDTAgJz4N3zrhwCYbd0qjjq1ig47TiT6cQ> <xmx:hzlMaDzmOaAJ5IYISBWYtzT-yjcO5XfP2dt3z8VpIlf7F0C5SxK_iQ> <xmx:hzlMaN6LtwXgE6tODcm61U4CjGNX8MGJwsavldONNqGxqynu144LfQ> <xmx:hzlMaAyTFT7ositsGME4jEKmQfr6B5kc8RReALAgDGjgDpJLx-KDEg> <xmx:hzlMaLTANM28gAJJz7nguAWu3g0f3j9KRV4aBScigATJA-FO6BZSuMAd> Feedback-ID: ie8a146a7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Jun 2025 10:45:27 -0400 (EDT) From: Steven Allen <steven@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections In-Reply-To: <86plf8duap.fsf@HIDDEN> References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> <87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN> <87v7p0ahs1.fsf@HIDDEN> <86plf8duap.fsf@HIDDEN> Date: Fri, 13 Jun 2025 07:45:25 -0700 Message-ID: <87ecvnhf96.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, rpluim@HIDDEN, larsi@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: Steven Allen <steven@HIDDEN> >> Cc: rpluim@HIDDEN, 78773 <at> debbugs.gnu.org, larsi@HIDDEN >> Date: Thu, 12 Jun 2025 12:20:30 -0700 >> >> Eli Zaretskii <eliz@HIDDEN> writes: >> >> >> I'll do that today. I have a suspicion that fast requests waiting on a >> >> single process exit early here: >> >> >> >> https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562 >> > >> > The condition for that block is >> > >> > if (wait_proc >> > && ! EQ (wait_proc->status, Qrun) >> > && ! connecting_status (wait_proc->status)) >> > >> > And the comment says "Don't wait for output from a non-running >> > process." Is the case here that the network connection was already >> > closed when we read from the sub-process? I thought that was not the >> > case. >> >> With my patch, it does hit that case, but on the third loop through so >> it's not exiting early. > > How come? What is wait_proc->status in that case? Note: this is WITH my original patch (to url.el), the one that makes it only wait on one process. In that case, the status is "run" the 1-2 loops through, then "exit" on the last loop (triggering this branch).
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 11:59:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 07:59:52 2025
Received: from localhost ([127.0.0.1]:43307 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uQ34Z-00034S-VP
for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 07:59:52 -0400
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:54565)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1uQ34V-00034A-T5
for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 07:59:49 -0400
Received: by mail-wm1-x334.google.com with SMTP id
5b1f17b1804b1-453398e90e9so3353415e9.1
for <78773 <at> debbugs.gnu.org>; Fri, 13 Jun 2025 04:59:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1749815981; x=1750420781; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=+wV7vjA31XJOQLX7GGlqVgGVPlt+Y7Brtfr7zLQqRfU=;
b=fZG0ZIsTZ3IoG5KmRqjf2ivXeOrFhCq2xV8r7RDR9xRB//EYkHLl6w3tjeeV2mNA7F
PbCrZudbLacqyKZSplJTfPgOBn03mROlZglwqLWGdNCjqL6wzjllz76qSzXVWfIJFjID
CVhDcd1U+G/BjWrZJc1kSLqghqF1EffwwG80CCQkuC3weVOLYhLi1R3eA/C0B5kFiPRD
LH6Z2tooq3my3CTKrm57ySw9v9mtst4eogewT3jU13490cIWA0dIeJ/2Lh25+xTJmlTW
zdlLDtCT1ku/BKHexL7WCOTxMJ9jaabhSk9C3YEopXqzim8cvpFbB0q14ZHRV91/vu13
RG3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1749815981; x=1750420781;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=+wV7vjA31XJOQLX7GGlqVgGVPlt+Y7Brtfr7zLQqRfU=;
b=Y4Q5Qm1jTClytZyTpcsaBYvGGwf+y4h9ziltZs1zck9kBng5E2hEVxCl+sdbyT9Mw9
L2L9QzxR/xA2SK7YtJj6PpWnjSwe2rk+GAWuxAxM8EtKGyW65wqCT3Qxw77CWtC2+zBY
o7Db+rSKdTEg/z+l3XdYg4p+vzqrfY64Rgf9fznWs9sdpt73G01s++0ItMHyTtemuGrK
I1CoqxjZu2u96XLbRNfEyPzujJn1heUrB1CGxp19K4B0UDgyAyiDgksZp+QfwxqBqQH9
rxNzIdnTfCHVaNQw6+GGDHQ165RpKXfGE7GBtqvMC7x9BIG5hDaDYavIyxMdcA1PVyJH
vZZA==
X-Forwarded-Encrypted: i=1;
AJvYcCXx8f5bL7lsBM5LetUQ7J6W7I8sbn5cJCwZGQhGnoMMvGrZ2Ihmsl2+MxW/PeoqIVUjhTWo9A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yyevppo1al1IW54I5BLmUu49m4NpZ+7sNHAY1WaYrDuNOdH7YEJ
2rzBodWZfNuKgQqTpVbzh35oTK00TVb55FBa740JoxnD6cAo3oFdDIAs
X-Gm-Gg: ASbGncvoRu1Fgn3+i0c8cdmZYsQxU45dicHNJEVklXM1ijb0u2QLd3odN2VymA5EsEp
9gj4HHCss3QPklOFw4wHiJ+1qFBZYttqQlal3f4EDIxr5MqERqLvQuqEDMMNyYvEgtdvrTq+agn
KPoknpfCpuCZzAGUp2ru+UgS1anBLIZ+Wp8Zr/LYJ3XTikQCrHslEcJCD3jt5soojjgeVLdAJfI
CRyfhBYacihxmFrqbdHP5N6k0wgoOnrreWOgN18z3cf7qs/urGeaXhPVWd8JM78oJbDaGZPPhyD
fwhAzOEMjk36LgM/EmBtbAV5rx/WME1/0jJDMcizCrLBWZYilvV8dBd54T5J
X-Google-Smtp-Source: AGHT+IGXIPVnQDaEz7/VhoxAt4XsTlRAuaSdMeotkRq3yGWQACAic12UeZq3IkFgbNiPqLBIToAdMg==
X-Received: by 2002:a05:600c:4f55:b0:43c:f629:66f4 with SMTP id
5b1f17b1804b1-453349acb61mr32003125e9.0.1749815981282;
Fri, 13 Jun 2025 04:59:41 -0700 (PDT)
Received: from rltb ([2a01:e0a:3f3:fb51:c51f:cac0:9d7b:73dd])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-4532e2618f0sm49791665e9.37.2025.06.13.04.59.40
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 13 Jun 2025 04:59:40 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <86jz5fex3r.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN>
<87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN>
<87bjqs9fxc.fsf@HIDDEN> <86jz5fex3r.fsf@HIDDEN>
Date: Fri, 13 Jun 2025 13:59:40 +0200
Message-ID: <874iwjam37.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN, steven@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
>>>>> On Fri, 13 Jun 2025 13:48:08 +0300, Eli Zaretskii <eliz@HIDDEN> said:
>> I=CA=BCm wondering why we=CA=BCre setting the timeout to zero and ca=
lling
>> `pselect' again, which means recomputing the wait set again, if I
>> haven=CA=BCt gotten lost in the twisty maze of if=CA=BCs and global =
variables
>> =F0=9F=98=80. We=CA=BCve got input, why can=CA=BCt we just `break'? =
There might be some
>> work we don=CA=BCt do, but that will get done the next time
>> `wait_reading_process_output' is called.
Eli> Try looking at the Git history of this code, maybe it will tell you
Eli> how this code evolved, and bring up past discussions and bug repor=
ts
Eli> which caused us to make the code as it is today.
Yes, it=CA=BCs gnarly. I think the following would be ok, and it passes the
test case for Bug#20978.
But I can=CA=BCt detect any difference in Steven=CA=BCs test case, so maybe=
we
let sleeping pselect=CA=BCs lie.
Robert
--=20
diff --git a/src/process.c b/src/process.c
index e61ec425f7e..0119330f7fe 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5934,6 +5934,7 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
channel_start
=3D process_prioritize_lower_fds ? 0 : last_read_channel + 1;
=20
+ bool break_now =3D false;
for (channel =3D channel_start, wrapped =3D false;
!wrapped || (channel < channel_start && channel <=3D max_desc);
channel++)
@@ -5975,8 +5976,11 @@ wait_reading_process_output (intmax_t time_limit, in=
t nsecs, int read_kbd,
if (nread > 0)
{
/* Vacuum up any leftovers without waiting. */
- if (wait_proc =3D=3D XPROCESS (proc))
- wait =3D MINIMUM;
+ if (!wait_proc || wait_proc =3D=3D XPROCESS (proc))
+ {
+ wait =3D MINIMUM;
+ break_now =3D true;
+ }
/* Since read_process_output can run a filter,
which can call accept-process-output,
don't try to read from any other processes
@@ -6119,6 +6123,8 @@ wait_reading_process_output (intmax_t time_limit, int=
nsecs, int read_kbd,
}
}
} /* End for each file descriptor. */
+ if (break_now) /* Don't rerun select. */
+ break;
} /* End while exit conditions not met. */
=20
unbind_to (count, Qnil);
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 10:48:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 06:48:19 2025 Received: from localhost ([127.0.0.1]:41819 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uQ1xL-0003FE-59 for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 06:48:19 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35268) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uQ1xI-0003Ew-QP for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 06: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 1uQ1xD-0003M6-8m; Fri, 13 Jun 2025 06:48:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=VopnovTtQsgbGimNFkfHFT9KDAOe76rIkpOpBjxXEl0=; b=FOsJlm/gs0LnuwjRjMsF cfMCYQZ2MMME37BO5EyBmRXJ7BTM0YeXxcvF8ItUYZ1Ybx+ZbwyNRwphcdlJg49cr03oq2whZeFSc lNjlRXkelv9dRQRADRHIammMw+45riqNFCxnoW67+4nIGcaIExoojP75pRaKvUT/iPPj8T3jttZzX 2smNUq/pjxPEymB7dQpa7MhedKe7Cv7zczUBIeYsW+J0N5X46694SfscSHnH7ihK4RKpc1Hu5EgSg pJUbNdG7xtdRj6tp7PimbVbNq5x+IWoUmA57KVS63MgkUZJaNj0asVv3TobNxaqWMQ35dXySHw8Vc RouKhlvfygu3sw==; Date: Fri, 13 Jun 2025 13:48:08 +0300 Message-Id: <86jz5fex3r.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Robert Pluim <rpluim@HIDDEN> In-Reply-To: <87bjqs9fxc.fsf@HIDDEN> (message from Robert Pluim on Fri, 13 Jun 2025 10:58:07 +0200) Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> <87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN> <87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN> <87bjqs9fxc.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN, steven@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: Robert Pluim <rpluim@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 78773 <at> debbugs.gnu.org, larsi@HIDDEN > Date: Fri, 13 Jun 2025 10:58:07 +0200 > > >>>>> On Thu, 12 Jun 2025 13:54:01 -0700, Steven Allen <steven@HIDDEN> said: > > Steven> Ok, I think I've figured it out. We loop twice and wait on a timeout > Steven> (READ_OUTPUT_DELAY_INCREMENT) the second loop because we're already done > Steven> reading. > > Steven> The first time through, we hit the following, recording that we've > Steven> gotten some output: > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5974 > > > Steven> We hit the following, setting our timeout to READ_OUTPUT_DELAY_INCREMENT: > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5679 > > Steven> Then we hit the select call and wait the full timeout (nothing to read) > Steven> and we finally exit here (because our timeout has passed): > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5832 > > Steven> *** > > Steven> I think what we need to do is modify: > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5978 > > Steven> from > > Steven> if (wait_proc == XPROCESS (proc)) > Steven> wait = MINIMUM; > > Steven> to > > Steven> if (!wait_proc || wait_proc == XPROCESS (proc)) > Steven> wait = MINIMUM; > > Steven> So that we set the timeout to 0 here: > > Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5439 > > Steven> And exit early. > > That analysis looks correct to me. It works for the original test > case, at least. I didn't yet have time to look into this closely enough to have an opinion. > I始m wondering why we始re setting the timeout to zero and calling > `pselect' again, which means recomputing the wait set again, if I > haven始t gotten lost in the twisty maze of if始s and global variables > 馃榾. We始ve got input, why can始t we just `break'? There might be some > work we don始t do, but that will get done the next time > `wait_reading_process_output' is called. Try looking at the Git history of this code, maybe it will tell you how this code evolved, and bring up past discussions and bug reports which caused us to make the code as it is today.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 08:58:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 04:58:23 2025
Received: from localhost ([127.0.0.1]:39587 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uQ0Es-0008K1-Ht
for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 04:58:23 -0400
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:48397)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1uQ0Ep-0008JB-PB
for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 04:58:16 -0400
Received: by mail-wm1-x32d.google.com with SMTP id
5b1f17b1804b1-450cfb6a794so11046875e9.1
for <78773 <at> debbugs.gnu.org>; Fri, 13 Jun 2025 01:58:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1749805089; x=1750409889; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=kAwHz/t9LjItrcQzLdHbqvTWfVUk6LKIoMMHQaI3Y/E=;
b=cHLtF/07aMPDy0kzhxo19Y8ae/jD5hBePrOPUdXk2QonumNsLzu3tge9k5HfIE5umP
TwY6lobR17bZ83iF7zZgjmX/OMlf7C1tIq/mqFdTquRLLv6X2sbDl/c6tCrXUy2Vx60I
J/5+TWd3W5TjRUb2Ql6O82iQE5RIgIokk9m7lbgbTncOZOplSBW6xSMDDqgF33pDfn6i
ENofu2RUYaQGcg78ArxJDkgrps4h/1VgW3ouPipxvJie5RM6OFh/4gr4OlxkpnVmPPBH
4tD9PamP8DnWWdnX5OlY4vcM4BiBaLcJYNSX0NSADKtUtfrye0OIHd6NwfOp+QFZlBgj
8gRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1749805089; x=1750409889;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=kAwHz/t9LjItrcQzLdHbqvTWfVUk6LKIoMMHQaI3Y/E=;
b=XFEcie6L3mco5b140NqxddJO/Z62n2uyNtSJ7XA/BKI0s9Yj0taXyagwD2BTHWkML3
sqQpuQnF6s2EV2fTTYKIQWbfsOGBJOiOCxPhIGjKmJpifzTpGaON5S4msh9kOJ1SjX/z
R1qX1w8SVSqqSaf0cRJTdwfIfMlehrJlbV1GyTuf4yQ+U/HWZRhPwEpJwHvklfrKDWQ1
o3a+wRxhY/7+3lDiPrLU0iPUCVTXpX82Dx/NYnGz/9G3+Qmt3bbMAv1KhJDlWbG98NXm
M2UKTkrdxZHmJFlewVDLUFxB9CGjHfciVPu9shb4wDTUtrE2i/i9K7tTmQBb9Q77krjp
zwgQ==
X-Forwarded-Encrypted: i=1;
AJvYcCV2Atw0j6+F+2nGnfgcqz0wOdBEXlGVSoMX58EUYxIoiAyKhO9Cokm1R4cn2iXOSDdLSA9Z7w==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwU5aM/mjLgHmGuoxwsVw/qimcEFFo+VIFlWP2N73iMruOwb3eL
VB4itlvASgHwRIovHKW6C7bo/judo/WQHSgJtAYlV1R0Ug3myQZBd4mg
X-Gm-Gg: ASbGnctrRK+go5pN1D2dTQDnjy71zMUCe1qifTOTrj0rOqJm2ocUVgX6FzwL6FzCmgD
BYpb8Tnob8SklAU0/VFyAOddDf2v7sNMetohL+SI6aAYQfIarr/3k74axY8EF626osbeai+JLRv
noJQgO78L+RPxwGrmKe1WHpsn+f/7DCt6Mz3AsmuzbqqHWUVNCqm2lYH6D0i0jRy0xcSSMnvuR3
nDFyJno8Y2fx3QAP/o0Zt/hEYZ9bASF4nTYtFlkQFAADzH0AgUYGb2CysFUGgwulXTCdiSYD5Bp
k8ApcJQ1jbzprkEBDKSJL568yLqZEE4eaeghjD8O4D9NCyT/eA==
X-Google-Smtp-Source: AGHT+IGf1w7OFlH7QzLbWylvs7oXR5afKc3OoBVoU0V142784OTcwrnWL6Bsyr9ktVU88QJKSJEMYQ==
X-Received: by 2002:a05:600c:138b:b0:442:ccf9:e6f2 with SMTP id
5b1f17b1804b1-45334b630ffmr22233415e9.16.1749805088752;
Fri, 13 Jun 2025 01:58:08 -0700 (PDT)
Received: from rltb ([2a01:e0a:3f3:fb51:c51f:cac0:9d7b:73dd])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-453305a0d9dsm39052945e9.21.2025.06.13.01.58.08
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 13 Jun 2025 01:58:08 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: Steven Allen <steven@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <87o6usadg6.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN>
<87v7p0ahs1.fsf@HIDDEN> <87o6usadg6.fsf@HIDDEN>
Date: Fri, 13 Jun 2025 10:58:07 +0200
Message-ID: <87bjqs9fxc.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, larsi@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
>>>>> On Thu, 12 Jun 2025 13:54:01 -0700, Steven Allen <steven@HIDDEN=
m> said:
Steven> Ok, I think I've figured it out. We loop twice and wait on a ti=
meout
Steven> (READ_OUTPUT_DELAY_INCREMENT) the second loop because we're alr=
eady done
Steven> reading.
Steven> The first time through, we hit the following, recording that we=
've
Steven> gotten some output:
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3D81a3e4e51167be51c63eae682331210bc62f7280#n5974
Steven> We hit the following, setting our timeout to READ_OUTPUT_DELAY_=
INCREMENT:
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3D81a3e4e51167be51c63eae682331210bc62f7280#n5679
Steven> Then we hit the select call and wait the full timeout (nothing =
to read)
Steven> and we finally exit here (because our timeout has passed):
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3D81a3e4e51167be51c63eae682331210bc62f7280#n5832
Steven> ***
Steven> I think what we need to do is modify:
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3D81a3e4e51167be51c63eae682331210bc62f7280#n5978
Steven> from
Steven> if (wait_proc =3D=3D XPROCESS (proc))
Steven> wait =3D MINIMUM;
Steven> to
Steven> if (!wait_proc || wait_proc =3D=3D XPROCESS (proc))
Steven> wait =3D MINIMUM;
Steven> So that we set the timeout to 0 here:
Steven> https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/pro=
cess.c?h=3D81a3e4e51167be51c63eae682331210bc62f7280#n5439
Steven> And exit early.
That analysis looks correct to me. It works for the original test
case, at least.
I=CA=BCm wondering why we=CA=BCre setting the timeout to zero and calling
`pselect' again, which means recomputing the wait set again, if I
haven=CA=BCt gotten lost in the twisty maze of if=CA=BCs and global variabl=
es
=F0=9F=98=80. We=CA=BCve got input, why can=CA=BCt we just `break'? There m=
ight be some
work we don=CA=BCt do, but that will get done the next time
`wait_reading_process_output' is called.
Robert
--=20
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 13 Jun 2025 06:34:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 13 02:34:22 2025 Received: from localhost ([127.0.0.1]:37499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uPxzY-0006WY-Gh for submit <at> debbugs.gnu.org; Fri, 13 Jun 2025 02:34:22 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43908) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uPxzT-0006Ub-EQ for 78773 <at> debbugs.gnu.org; Fri, 13 Jun 2025 02:34: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 1uPxzN-0004Q2-IL; Fri, 13 Jun 2025 02:34: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=qDLmA2kuvSkN2wlh+874YbTq+m7PhNT+XNz7xxPRFQY=; b=eR3Zaf4ZadoV Ca7UYX7OsWdahcx6oyzu6Zbf6rwaITBelVm1jDqv+Ni+6pPTt0NVwtoKw1EnHKJs9FnY/m5dx0H59 PnCEBfGSXyoKCnlZNjj9dBy3DCC8qLCK5k3EHRdKbBnXExgMJBK1xRyy+ZiEP2+kvv5WEYsunXG1I LjAvfu25wJrM63KNbBhNQmwvILjHX7ZDhbqumdZEc9tG2hP286HOnlNZEghctNV4KNzxN5VqlnttR H6/em5k4w+pJEcuaB5VJmg6ygyBub9WjAJgvRu3wZJq542/n5AKwt+P5vZeQ+ORG/tnOaCjy4h2gA 40MzuAz+KaWzJ7dCQa0lsg==; Date: Fri, 13 Jun 2025 09:34:06 +0300 Message-Id: <86plf8duap.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Steven Allen <steven@HIDDEN> In-Reply-To: <87v7p0ahs1.fsf@HIDDEN> (message from Steven Allen on Thu, 12 Jun 2025 12:20:30 -0700) Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> <87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN> <87v7p0ahs1.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, rpluim@HIDDEN, larsi@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: Steven Allen <steven@HIDDEN> > Cc: rpluim@HIDDEN, 78773 <at> debbugs.gnu.org, larsi@HIDDEN > Date: Thu, 12 Jun 2025 12:20:30 -0700 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> I'll do that today. I have a suspicion that fast requests waiting on a > >> single process exit early here: > >> > >> https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562 > > > > The condition for that block is > > > > if (wait_proc > > && ! EQ (wait_proc->status, Qrun) > > && ! connecting_status (wait_proc->status)) > > > > And the comment says "Don't wait for output from a non-running > > process." Is the case here that the network connection was already > > closed when we read from the sub-process? I thought that was not the > > case. > > With my patch, it does hit that case, but on the third loop through so > it's not exiting early. How come? What is wait_proc->status in that case?
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 20:54:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 16:54:13 2025
Received: from localhost ([127.0.0.1]:32843 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uPow8-0006Q8-Bs
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 16:54:12 -0400
Received: from fhigh-b1-smtp.messagingengine.com ([202.12.124.152]:57641)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steven@HIDDEN>)
id 1uPow5-0006Pl-4W
for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 16:54:09 -0400
Received: from phl-compute-06.internal (phl-compute-06.phl.internal
[10.202.2.46])
by mailfhigh.stl.internal (Postfix) with ESMTP id 5581D2540092;
Thu, 12 Jun 2025 16:54:03 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
by phl-compute-06.internal (MEProxy); Thu, 12 Jun 2025 16:54:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com;
h=cc:cc: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=1749761643; x=
1749848043; bh=FynnKFuVSidWqpxJgQvO20Jb2ANTX4zw0IEILpYaSGc=; b=n
aiQEjvdmd+GOas/OXNmEWnOJ4ZFemEcggYnFZ/mCsobwXEnl8Uae4ZDjrQ+7iRY6
6nJKm8A2dQbMJgmzYYTOip7OOdR72jCCs1Q4qV28zhP68UBmoRFkY3N3Jvx1uCus
TaHl1PdrTMz+7tEl0Q7lfOxJmqiHO4+2pkfFMbiSNHyD+tNjwjrdgKr8fqb5CUhM
XFcpfdhNegGFJtrkvzDyYkJz5N/jKTQEv6eNtHH6bw3/N/strETFmLSFnj+dvsNQ
w6z6JQduGocBzfKip1acnrILYuDGAMo98woZZv2MhYJyr5GUoBVhB0GbuUpIaQrw
D5P5GxRAgNbcsvSUuO/Dg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc: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=
1749761643; x=1749848043; bh=FynnKFuVSidWqpxJgQvO20Jb2ANTX4zw0IE
ILpYaSGc=; b=WUZzcKohsm7KBHjA7pbNLN303S527GEZ1c/cDw4sGxOczfz4Tq1
SgI4s4SpHUNiLwdAUvT9YefxTzhYdE1Vn+SuPBEudnL4wMhcOVrcSthHfQBWHx2r
PWmo57G89R8T14+uZKrD+nnVspSN7A0oKObWcnHhnnbAXE+6M+hXNzLlNQ0foT8r
50Tl7XCQ1c7ph8WojgGuqf24a0Y5eoI993S5wGMcVwyaDxpmvnVwEF1Llf/FFcHA
2PEBZ6Gso61XBpTe7stViqqxA32vCpak/I73P5sskJqg4tSi8ERmpqRJBJ/MWdIa
uPwWqUd8Mhe5TPyt3g2s1CUoa+1wTQMvkiw==
X-ME-Sender: <xms:aj5LaMxRUcQqPthn-VSXH9RHkcdTsCzLHmLLBwkjYcYmVeFvw172cA>
<xme:aj5LaAQ4Iz5mY3XKP5xqhO2Bx5hvly97DlCKFEJp_u0gApu05CDOr962-hXZDQ25F
ab8H_maZ6d5JTq5pDU>
X-ME-Received: <xmr:aj5LaOXJYiyaAmqIH3QuCgGqE3fME2Uz-VOGYOOzSjUk9V5FV1Tb-n_BPD8FJHKSanSScn-UDXWbYFWb7If15bH-KD-0m9c>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduiedtkecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesmhdtreertddttden
ucfhrhhomhepufhtvghvvghnucetlhhlvghnuceoshhtvghvvghnsehsthgvsggrlhhivg
hnrdgtohhmqeenucggtffrrghtthgvrhhnpeeitedvhfffuefhtdeutdegfeegieeiteev
vefgueefieevvdehfeejffffgfevjeenucffohhmrghinhepghhnuhdrohhrghenucevlh
hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgvvhgvnhes
shhtvggsrghlihgvnhdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph
houhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtoheprhhplhhu
ihhmsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeekjeejfeesuggvsggsuhhgshdrgh
hnuhdrohhrghdprhgtphhtthhopehlrghrshhisehgnhhushdrohhrgh
X-ME-Proxy: <xmx:aj5LaKggc6HuHmqOALkIwBI7yigx1aOZ7rvAWvpRirMyM6ZynU_nWg>
<xmx:aj5LaOCbfzTt08qZyPQ2OeHVOdwZ8oeF9ZV-1-fPn2t4gW7lukVOeg>
<xmx:aj5LaLI6x3O1caM90Whpf-eJsbUdH4YJx3nRph3DHHzcYv1DHplkXQ>
<xmx:aj5LaFB7RTVH5vlDdIRQ95yiqhYHJYY83SGcZ2W4AFO2ChsJPG2_Sw>
<xmx:az5LaL9Qn9A9X18D71HIvEBdajsc4ZYO_Db05Ws09TME19XmCnVeyS9l>
Feedback-ID: ie8a146a7:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
12 Jun 2025 16:54:02 -0400 (EDT)
From: Steven Allen <steven@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <87v7p0ahs1.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN>
<87v7p0ahs1.fsf@HIDDEN>
Date: Thu, 12 Jun 2025 13:54:01 -0700
Message-ID: <87o6usadg6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, rpluim@HIDDEN, larsi@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 (-)
--=-=-=
Content-Type: text/plain
Steven Allen <steven@HIDDEN> writes:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Steven Allen <steven@HIDDEN>
>>> Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN
>>> Date: Thu, 12 Jun 2025 11:02:41 -0700
>>>
>>> > Perhaps instrumenting wait_reading_process_output with printf's would
>>> > help to understand the control flow in the case of nil and non-nil
>>> > PROCESS argument?
>>>
>>> I'll do that today. I have a suspicion that fast requests waiting on a
>>> single process exit early here:
>>>
>>> https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562
>>
>> The condition for that block is
>>
>> if (wait_proc
>> && ! EQ (wait_proc->status, Qrun)
>> && ! connecting_status (wait_proc->status))
>>
>> And the comment says "Don't wait for output from a non-running
>> process." Is the case here that the network connection was already
>> closed when we read from the sub-process? I thought that was not the
>> case.
>
> With my patch, it does hit that case, but on the third loop through so
> it's not exiting early.
>
> I also tried setting the timeout in `accept-process-output' to nil and
> that got me the same speedup as my fix but ended up looping 23 times so
> there's something really strange going on with the timeout here.
Ok, I think I've figured it out. We loop twice and wait on a timeout
(READ_OUTPUT_DELAY_INCREMENT) the second loop because we're already done
reading.
The first time through, we hit the following, recording that we've
gotten some output:
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5974
We hit the following, setting our timeout to READ_OUTPUT_DELAY_INCREMENT:
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5679
Then we hit the select call and wait the full timeout (nothing to read)
and we finally exit here (because our timeout has passed):
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5832
***
I think what we need to do is modify:
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5978
from
if (wait_proc == XPROCESS (proc))
wait = MINIMUM;
to
if (!wait_proc || wait_proc == XPROCESS (proc))
wait = MINIMUM;
So that we set the timeout to 0 here:
https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5439
And exit early.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Exit-accept-process-output-early-when-we-get-output-.patch
From 0772d96d50734fff14a17b2f207661418f5c814c Mon Sep 17 00:00:00 2001
From: Steven Allen <steven@HIDDEN>
Date: Thu, 12 Jun 2025 13:48:08 -0700
Subject: [PATCH] Exit accept-process-output early when we get output from any
process
Previously, the caller requested to wait on output from any process (not
a specific process), we'd always end up waiting
10ms (READ_OUTPUT_DELAY_INCREMENT) one final time before returning.
* src/process.c (wait_reading_process_output): abort waiting early if we
either receive output from the process we were waiting on OR we weren't
waiting on a process.
---
src/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/process.c b/src/process.c
index e61ec425f7e..7b8fd1357e3 100644
--- a/src/process.c
+++ b/src/process.c
@@ -5975,7 +5975,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
if (nread > 0)
{
/* Vacuum up any leftovers without waiting. */
- if (wait_proc == XPROCESS (proc))
+ if (!wait_proc || wait_proc == XPROCESS (proc))
wait = MINIMUM;
/* Since read_process_output can run a filter,
which can call accept-process-output,
--
2.49.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 19:20:42 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 15:20:41 2025 Received: from localhost ([127.0.0.1]:60625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uPnTd-0008Tv-CN for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 15:20:41 -0400 Received: from fhigh-b8-smtp.messagingengine.com ([202.12.124.159]:54475) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steven@HIDDEN>) id 1uPnTZ-0008TQ-V4 for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 15:20:38 -0400 Received: from phl-compute-06.internal (phl-compute-06.phl.internal [10.202.2.46]) by mailfhigh.stl.internal (Postfix) with ESMTP id 55C7C25402F1; Thu, 12 Jun 2025 15:20:32 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Thu, 12 Jun 2025 15:20:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com; h=cc:cc: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=1749756032; x= 1749842432; bh=Ue/ifrVf8tJ7LVewsm/tpQZk9qn0Np6uF2zM3Mkfc7w=; b=Q bFNo1L28z2zGVDZnCaaWTeGMKJX+Pz9lEuOdmAXZLJpGLoXUfVNolqrvnGML7liS bqhRU4BH3OH+9e2BLxAQoQ/uQ+T5Fo1SERgIBzDJueHh1LlyKV9HW7XKStSvLdmB OW2c0ytNyzhEJ+tM+bkArUNs77SR+JKdgJOKXaQYWV0loEc/4SJa1HhFKkGPnYL/ CRMAxvflz0RDgiFndjCVWxhavfSZfXkRVDR9ruUTn2URK9XlDAJLXx5aDeeoQ1/C k0D3BSVkG6t5JDf1jFWtORoLYJTw8ec7/x8Yiwp+GEATriVandSfnPEa1rolyKBn Lj7YXcZn1AV6WKpiyzRFQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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= 1749756032; x=1749842432; bh=Ue/ifrVf8tJ7LVewsm/tpQZk9qn0Np6uF2z M3Mkfc7w=; b=BXbFO/dJq904y5RWhTiOXL5KoJjgexTfdqs8IQ9pbYr59oaBNKU DZ5l+FqL83n7RZ5dfo4nsmKX+x4W0jM4TxTWF3lXPMOGuy8w8ZNz+L+n5nYHXc7t hCd/SQ2GXkCpsZ7e0ax/IaH+p8+7cSE0KeSuuw2R6sj6/cR8hSWdZBlzUUdt/EhM QW7mWzF14EXGLFcpNs2hyOshewoGkkfP/zHsU/LNZy+87JL0gHPlELoc9PNwVNwG oeCK+ikQb8knVjFxmwbxaIUbknULb/LiFTcA8ZQN7vmLkMbndx3qNLf/fxmwAwSJ wlRuUoyRHLgL6w8HF/f+sCgK36cB/4BC/OQ== X-ME-Sender: <xms:fyhLaCGbUowj0mxDdRA2vkDqhhwEaRK4SYIR00zspVK_iQLiZ221-g> <xme:fyhLaDXP7d7tbtRw7-MM4UoBC7jOsu8Lp6kQEwOyo8I8xEKI6kaXGTIsUda2XnxVU siLLGnrNrsJBJlw9j4> X-ME-Received: <xmr:fyhLaMIvp4U6qU_l5WWHv2Pm138NTZgVvLxvBrzr_ctZ181I04aKlqVwaYW8oNvd3LnOfF7dgYfhYpjadEN0MbTATTnklbw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduheeklecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesthdtredttddttden ucfhrhhomhepufhtvghvvghnucetlhhlvghnuceoshhtvghvvghnsehsthgvsggrlhhivg hnrdgtohhmqeenucggtffrrghtthgvrhhnpeejffefuddvieefgeevkeeggfelhefhffeg leetffetuedttefggeffheeufeektdenucffohhmrghinhepghhnuhdrohhrghenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgvvhgvnhes shhtvggsrghlihgvnhdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmhhtph houhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtoheprhhplhhu ihhmsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeekjeejfeesuggvsggsuhhgshdrgh hnuhdrohhrghdprhgtphhtthhopehlrghrshhisehgnhhushdrohhrgh X-ME-Proxy: <xmx:fyhLaMEN06SSqkwaCFPAQPrAS_x8eV9BiKNgs0JmuCnBrdWgeZW5Iw> <xmx:fyhLaIUFaBRDjuxGI2pDVLimp9JebVSXJ7qWWXMH4HrF5UG5vpU0xA> <xmx:fyhLaPNzwhK1EHYk-6VRquHydBIwguvIIL-j2e2d-xbJgy8vOiFdkA> <xmx:fyhLaP1BmcG_TpzGLYMius-IwEFGgYQZjzL6L5Odh9CKqZ4TSguXlw> <xmx:gChLaK0ujBBbj4SvOhTyHk2m11KZeYNsv_QVOX5Bg9KyuMknSuQ02-JS> Feedback-ID: ie8a146a7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Jun 2025 15:20:31 -0400 (EDT) From: Steven Allen <steven@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections In-Reply-To: <86zfecerva.fsf@HIDDEN> References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> <87y0twdeim.fsf@HIDDEN> <86zfecerva.fsf@HIDDEN> Date: Thu, 12 Jun 2025 12:20:30 -0700 Message-ID: <87v7p0ahs1.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, rpluim@HIDDEN, larsi@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: Steven Allen <steven@HIDDEN> >> Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN >> Date: Thu, 12 Jun 2025 11:02:41 -0700 >> >> > Perhaps instrumenting wait_reading_process_output with printf's would >> > help to understand the control flow in the case of nil and non-nil >> > PROCESS argument? >> >> I'll do that today. I have a suspicion that fast requests waiting on a >> single process exit early here: >> >> https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562 > > The condition for that block is > > if (wait_proc > && ! EQ (wait_proc->status, Qrun) > && ! connecting_status (wait_proc->status)) > > And the comment says "Don't wait for output from a non-running > process." Is the case here that the network connection was already > closed when we read from the sub-process? I thought that was not the > case. With my patch, it does hit that case, but on the third loop through so it's not exiting early. I also tried setting the timeout in `accept-process-output' to nil and that got me the same speedup as my fix but ended up looping 23 times so there's something really strange going on with the timeout here.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 18:29:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:29:18 2025
Received: from localhost ([127.0.0.1]:60314 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uPmfu-0004vp-Ei
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 14:29:18 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36226)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uPmfr-0004vb-Lb
for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 14:29:16 -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 1uPmfm-0006E1-43; Thu, 12 Jun 2025 14:29:10 -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=Af6wgzBN4MRUYabkAB/9Y0DUSzakS+tFNWI0+eMzQg8=; b=KB89Tz0APyMJ
h5wQdXG96oAawwEi+m22YlhoUzKkWBF6xwhvQhutAKfMLVzuC1DSX+hzVnQklvtxBzQ8UGVd0zzp0
6nYOQQyqj5yw1cKXhek5GzVfndJDaUsz+G8z/PybNZS2ySLzogYmBU7Z5wsZa/V/107gLNZyagWvV
NV6YyyY0DuJoguogqMjcaePsZQxKlhN0DnW4HGk64Ut9BMVNYzZFeQlAlLlvdimNQHXs12k3LZhns
r013wRr9GMDx+KM4XMTph9dIz53RM834RzoM49kNxZVzy/ltXbE8lp66jvXIabBipwjONsXtK309F
ywCKSc4eyvO3u2sSFVd9zA==;
Date: Thu, 12 Jun 2025 21:28:57 +0300
Message-Id: <86zfecerva.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Steven Allen <steven@HIDDEN>
In-Reply-To: <87y0twdeim.fsf@HIDDEN> (message from Steven Allen on Thu,
12 Jun 2025 11:02:41 -0700)
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
<87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN>
<87y0twdeim.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, rpluim@HIDDEN, larsi@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: Steven Allen <steven@HIDDEN>
> Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN
> Date: Thu, 12 Jun 2025 11:02:41 -0700
>
> > Perhaps instrumenting wait_reading_process_output with printf's would
> > help to understand the control flow in the case of nil and non-nil
> > PROCESS argument?
>
> I'll do that today. I have a suspicion that fast requests waiting on a
> single process exit early here:
>
> https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h=81a3e4e51167be51c63eae682331210bc62f7280#n5562
The condition for that block is
if (wait_proc
&& ! EQ (wait_proc->status, Qrun)
&& ! connecting_status (wait_proc->status))
And the comment says "Don't wait for output from a non-running
process." Is the case here that the network connection was already
closed when we read from the sub-process? I thought that was not the
case.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 18:02:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 14:02:52 2025 Received: from localhost ([127.0.0.1]:60200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uPmGJ-0003C9-FA for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 14:02:51 -0400 Received: from fout-b2-smtp.messagingengine.com ([202.12.124.145]:47423) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <steven@HIDDEN>) id 1uPmGH-0003Bo-Gi for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 14:02:50 -0400 Received: from phl-compute-02.internal (phl-compute-02.phl.internal [10.202.2.42]) by mailfout.stl.internal (Postfix) with ESMTP id 8692F11401D1; Thu, 12 Jun 2025 14:02:43 -0400 (EDT) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-02.internal (MEProxy); Thu, 12 Jun 2025 14:02:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com; 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=1749751363; x=1749837763; bh=Nz1pAdw9T8ZoJyoRqn0N8Q2VQeLvAp0W taPsTsALrWQ=; b=qfVq2WwkqxMK6TLif4rywZHTkG/oEV8zBdbvffSn+kNxZWQo AFhxdpeL36FAbQWvQlGhndjL5ISzZSDzrS9Bcs9NYPlTGqhIZdUUzOMITWCVjk0r j4W6IPDsL8Y+jjwZv9OBrjw+NkiMRsc6XMo/UtNwIGgu1QkJkYP1kzE+m7KY47qm XsohzdKiZSiooNuCGacDRpmD1sIw05CJQe0p0BF8OwiU2ass7eNzxxJcF8HSrGRo XoRWufyzpLqWGRvJUMLTx2Wv133jPuf5zYNy1XPd920pl0fH7Vvv/IJ9ytM3ZaO8 wlbT4o32mAyxak572PMJQVBD3aFPihMqDFlgtw== 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=1749751363; x= 1749837763; bh=Nz1pAdw9T8ZoJyoRqn0N8Q2VQeLvAp0WtaPsTsALrWQ=; b=h P1L85GWxo9YwFbxxC7xb0awXDoSbrKeeSjJd3isH/wi+cAGsyySzeaNZfqkHFyr6 itxhbZJVfzcLY4CkU5xiffaLq4oED7My/rPQFDHL3y6H5dt7n597QuGCQb4VnjFN rePa5EPRzGpytt6BuCqWa+HHcy793GvZHNqqi7HAaQONso7kVVrWcMAClxz1OVoc gAkB+R7GvCInZVl8PGbjlN6kWCCz+SBrA8u1U5bWpOJBk7JU6JKHQldYZU1BHAnt 2iUKhAt9tvGeXWqH7SQ+y+gYm8QJle6U9IB3fdUM4px8qJwiVc49HiYF+FLg9VfS YdbVEws0iHgyxQsHRR9uA== X-ME-Sender: <xms:QhZLaAHF_TzU1xILInU4meff1Rc19Hkl2hlOSMcfD8KfLtGw3Vnoqg> <xme:QhZLaJXj7blx2BK0jydkStB9ev-Te5gyWVGcOzN3r3rzHK3DQVLD_9W38cN8wUqdg wDSf-r59E0atIsR89c> X-ME-Received: <xmr:QhZLaKIcft-E_fC32RmeioJ4YmZbZLnkUV1WSeshlmTYsllDCAXmeIqAGDGYmqCwtQcfF-rhovw8rEWlyINf4B3GXAeFPCE> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduheejgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgfgsehtqhertddttdej necuhfhrohhmpefuthgvvhgvnhcutehllhgvnhcuoehsthgvvhgvnhesshhtvggsrghlih gvnhdrtghomheqnecuggftrfgrthhtvghrnhepudevlefgtdekheekgffhtdegheduhfeg tdfgffefteetgfetkeeivddthefhkeetnecuffhomhgrihhnpehgnhhurdhorhhgnecuve hluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtvghvvghn sehsthgvsggrlhhivghnrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmth hpohhuthdprhgtphhtthhopegvlhhiiiesghhnuhdrohhrghdprhgtphhtthhopehrphhl uhhimhesghhmrghilhdrtghomhdprhgtphhtthhopeejkeejjeefseguvggssghughhsrd hgnhhurdhorhhgpdhrtghpthhtoheplhgrrhhsihesghhnuhhsrdhorhhg X-ME-Proxy: <xmx:QhZLaCEpp5w2uTOeRy1Z29bU9N1i4A4k7E9d7fDXNlaMp3rVaE2VSA> <xmx:QhZLaGXtz6ZY3F64sgm7MLlz0uEVBvqxNtoFGxTTbjjRKMyQstCmlw> <xmx:QhZLaFNu08WzD4tZwmemEtrD7GFdwWCI_uC8DonbYkksFy7kxgUBOA> <xmx:QhZLaN0cRlG91ooUIsbUN9YaK0CmNhX_j8dqJ0ZLyd4Uu5LV4ASDkw> <xmx:QxZLaJC77It73QNJI8hQa1ov8Dkr4klujCw1qz__HLpu0CY-4y4C0jtb> Feedback-ID: ie8a146a7:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Jun 2025 14:02:42 -0400 (EDT) From: Steven Allen <steven@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Robert Pluim <rpluim@HIDDEN> Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections In-Reply-To: <86ldpxfc68.fsf@HIDDEN> References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> <86ldpxfc68.fsf@HIDDEN> Date: Thu, 12 Jun 2025 11:02:41 -0700 Message-ID: <87y0twdeim.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, larsi@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: >> The fact that it=CA=BCs localhost shouldn=CA=BCt matter. The code in que= stion is >> convoluted, as you well know, so figuring out what=CA=BCs going on needs= us >> to have a good understanding of which cases trigger this >> behaviour. But the evidence so far points at the handling of the >> timeout. > > In the case of a remote host, the speedup was marginal, so I think > the localhost does matter, somehow. It looks like a latency thing. It's not that it's localhost specific, it's that the effect is more pronounced on low-latency connections because something, somewhere is adding a tiny delay (likely the timeout). When I test against my router (10ms latency, how awful!), I get a 1.25x speedup (1.2x speedup with just your timeout change). I've also tested with IP addresses and reproduced the same results, so it's not related to DNS lookups. > Perhaps instrumenting wait_reading_process_output with printf's would > help to understand the control flow in the case of nil and non-nil > PROCESS argument? I'll do that today. I have a suspicion that fast requests waiting on a single process exit early here: https://https.git.savannah.gnu.org/cgit/git/emacs.git/tree/src/process.c?h= =3D81a3e4e51167be51c63eae682331210bc62f7280#n5562 >> But the evidence so far points at the handling of the timeout. I can say that we're definitely NOT waiting for the timeout: increasing the timeout (to, e.g., 1-2s) doesn't slow things down. I suspect having a really short timeout is causing us to abort wait_reading_process_output early before it hits some expensive part.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 17:27:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 13:27:25 2025
Received: from localhost ([127.0.0.1]:60044 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uPli0-0000lq-Ow
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 13:27:25 -0400
Received: from fhigh-a6-smtp.messagingengine.com ([103.168.172.157]:37201)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steven@HIDDEN>)
id 1uPlhx-0000lQ-Io
for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 13:27:22 -0400
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
[10.202.2.45])
by mailfhigh.phl.internal (Postfix) with ESMTP id C50101140215;
Thu, 12 Jun 2025 13:27:15 -0400 (EDT)
Received: from phl-mailfrontend-02 ([10.202.2.163])
by phl-compute-05.internal (MEProxy); Thu, 12 Jun 2025 13:27:15 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com;
h=cc:cc: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=1749749235; x=
1749835635; bh=bVgSSrGMo+vnzx7nAMxa7Q/0vIbgFeZyxYf2j+SgWtA=; b=a
wYYcXgK6HPoERVCp72MWkCbX62gDBY5Na98sc3jxE4paLbG1Jzk+Sk3xBkXfG7l8
svqmj30NqsdyAt486zPZ0B+91+L8GxuYciaRWAcmz6W7LnSt4dhU6VVsSKCeoJsi
v7yiyWuFpyt2qL7U0FTQS3TGyXZYaLaa1hYzqkVuQfEv6isOkygapRSxywlj17i8
z54qYElUx4OZoYJmNEHfKUM3PaY3xENXFT/QgC3g8oD3HGTQubn7FAan1t9VzTt8
/7J2+TA9/sWzYxIomBH5RvzAdFX4Pqa9Ov172lE2mhh2aluOJYjaOqVt6riL8a/1
q/EhZtZ1yVDTb5l5lxrIg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc: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=
1749749235; x=1749835635; bh=bVgSSrGMo+vnzx7nAMxa7Q/0vIbgFeZyxYf
2j+SgWtA=; b=B6t3gokCduYAamu/MoT97j1tFFO92MWGZMLA6d1hVeU2xoRJXZu
9mHxnbgEbKomqQIRUaCswwxbiXXMvuReLs+Yja1a2cPed27grvDvr7gxuoKcckoN
QXgjsl3qW2kjNnOfaFGBJXix7TjOzFxfMxG7fNWrZOHcyESA3VKRStgyXqfm4Hix
5EfLMoQbUd+FcPLCbGSS4VTqIeHLC46Obo+ozpZn5f/qhtL/6Hfvim/yIJcU4WtM
zP7sgNDEa7Bo6dAus0p2y4b5hHw1VZc3s556G0zmNtTapK5JJRP+5L4+5v34G10F
zR+NZvuFhQY6dcvmG5MWe7kSE0MWY1pSwtA==
X-ME-Sender: <xms:8w1LaMfHtm9-Yq_LknIic1DCc6J7-6oh29pWTIJEHVeyvUGdVcoZZQ>
<xme:8w1LaOP1uc1vRM1_awWUiwq0TWtNA9b0WPvaFaK-ANZF1gyl8MJueY50l0GfdwHPY
WQAf4Chvuf9J9NkMvE>
X-ME-Received: <xmr:8w1LaNj7uykStxQ_zfCHE79KrqupaMOV0z9J8m1h5sUvHIRbi1MiKZB7Wf-elrcsCwpZhDgb8tGSvyY58cbuidjDEyq_7GI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugdduheeijecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
hnthhsucdlqddutddtmdenucfjughrpefhvfevufgjfhffkfggtgesthdtredttddttden
ucfhrhhomhepufhtvghvvghnucetlhhlvghnuceoshhtvghvvghnsehsthgvsggrlhhivg
hnrdgtohhmqeenucggtffrrghtthgvrhhnpeehgeffteevudefuedvfefhgeduffethfel
uedtvddutdejgfetgeetgfeitdevgfenucffohhmrghinhepuddvjedrtddrtddrudenuc
evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthgvvhgv
nhesshhtvggsrghlihgvnhdrtghomhdpnhgspghrtghpthhtohepgedpmhhouggvpehsmh
htphhouhhtpdhrtghpthhtohepvghlihiisehgnhhurdhorhhgpdhrtghpthhtoheprhhp
lhhuihhmsehgmhgrihhlrdgtohhmpdhrtghpthhtohepjeekjeejfeesuggvsggsuhhgsh
drghhnuhdrohhrghdprhgtphhtthhopehlrghrshhisehgnhhushdrohhrgh
X-ME-Proxy: <xmx:8w1LaB-3UWlUGvsR3D4rGYZAmSEQG1-jj0TLjKLYLQN7tFdF5ExDDw>
<xmx:8w1LaIuWKDGN7Nb690joQUf23-qYD1HO106Wlphwnz2lVQs6X0kOfA>
<xmx:8w1LaIGXkzhHYwpieN0lhwvhmS4GceJLG1XwSkPnCnXknHDv1SXuyg>
<xmx:8w1LaHP5fqwPV-IUqnW1XV90hVroh7WyxCc7kp1AtFr4fWxhQHWGQQ>
<xmx:8w1LaNNmwum5fro56zmaoQKTUWe_vCcYJKyt600jJzmu11lgezOkq68g>
Feedback-ID: ie8a146a7:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
12 Jun 2025 13:27:14 -0400 (EDT)
From: Steven Allen <steven@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>, Robert Pluim <rpluim@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <8634c5h30i.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
Date: Thu, 12 Jun 2025 10:27:13 -0700
Message-ID: <871proeuq6.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, larsi@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:
>> With this one change, this code goes back to being as slow as it was before.
>
> What happens if you leave the 1st argument of accept-process-output at
> its current nil value, but change the 2nd argument to be 0.005 instead
> of 0.05 (i.e., 10 times smaller)?
Now testing with:
emacs -Q --load=url.el --batch --eval \
"(benchmark 100 '(url-retrieve-synchronously \"http://127.0.0.1:8000\"))"
- Changing the timeout from 0.05 to 0.005 drops the time from 1.25
seconds to 0.63 seconds (~2x faster).
- My patch drops it to 0.056 (22x faster in a clean environment).
However note: changing the timeout from 0.05 to 0.005 makes the wait
loop spin 6 times for higher latency (non-localhost, ~40ms) requests whereas it
loops exactly once with the default timeout.
> Also, how many other sub-processes (of any kind, not just network
> processes) do you have in that session when you are testing this
> issue?
From list-processes, 13-14 when testing this originally (including network
processes, listening sockets, etc.).
>> However, the patch in question also changed the rest of
>> `url-retrieve-synchronously' so I'm hoping the issue lies elsewhere?
>
> Unfortunately, I doubt that we will get any useful answers to this
> question. We need to understand better why asking for output from a
> single process has such a dramatic effect in your case with localhost
> requests. If it happens only with localhost requests, perhaps we
> could make some changes only for that case.
Testing with a server with a 30ms latency (tested with "emacs -Q"), I get:
1. A 1.4x speedup with my patch.
2. A 1.3x speedup by simply changing the timeout.
But there's a lot more noise in the higher-latency tests.
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 11:10:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 07:10:34 2025 Received: from localhost ([127.0.0.1]:56843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uPfpK-0002Wn-Em for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 07:10:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42258) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uPfpI-0002W6-D2 for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 07:10:33 -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 1uPfpC-0004r3-AI; Thu, 12 Jun 2025 07:10:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=tm0rVmm18pcFN8P+GaMLSvijCMxHGm/Hf9RkFBRIN+4=; b=NhrGIJuidVAjnN1G2cIM ReYzxKakniN6ulsQRbk/gZ094uVMxpN1qwIQUp5bY9G2u2A+5JjiOmXMEaAVyQJvxs/fmsPCwzm8f FKg+UPLj9O/wGxVPPKQOHXYtZB2KmQP1GcLxl1Ue6R+sZacPhDDEitRbPjxZ/Yaq96MaOs/8gVwf9 JxJZgkJ+EHLxjauqpCcwuXJhxFNzxzvrh0DCW7fxUYqVwAElFcstt3chp8CFE+yc3yxeoIK36spDc XmUTOl1KjwncbX6uOU/ellNOek+/qrzEMjs8ftihs1lMbAsJE1juIAiF1F4M84RF+gtx/aj7Qznpo 0cp8W4e29Hd6jQ==; Date: Thu, 12 Jun 2025 14:10:23 +0300 Message-Id: <86ldpxfc68.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Robert Pluim <rpluim@HIDDEN> In-Reply-To: <87frg59wsa.fsf@HIDDEN> (message from Robert Pluim on Thu, 12 Jun 2025 10:41:41 +0200) Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN> <87frg59wsa.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN, steven@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: Robert Pluim <rpluim@HIDDEN> > Cc: Steven Allen <steven@HIDDEN>, 78773 <at> debbugs.gnu.org, > larsi@HIDDEN > Date: Thu, 12 Jun 2025 10:41:41 +0200 > > >>>>> On Thu, 12 Jun 2025 09:45:17 +0300, Eli Zaretskii <eliz@HIDDEN> said: > > Eli> What happens if you leave the 1st argument of accept-process-output at > Eli> its current nil value, but change the 2nd argument to be 0.005 instead > Eli> of 0.05 (i.e., 10 times smaller)? > > That speeds it up, although not as dramatically > > Eli> Also, how many other sub-processes (of any kind, not just network > Eli> processes) do you have in that session when you are testing this > Eli> issue? > > The answer to that is important, since there are a couple of loops in > `wait_reading_process_output' that depend on that, and can trigger DNS > or TLS operations as a result. But I始ve just tested this in 'emacs -Q' > with zero processes, and I see the speedup. If this happens with a single sub-process, it's strange. It means that we somehow wait for the full timeout even though some output from the single sub-process arrives, which should have ended the wait. Or what am I missing? > Eli> Unfortunately, I doubt that we will get any useful answers to this > Eli> question. We need to understand better why asking for output from a > Eli> single process has such a dramatic effect in your case with localhost > Eli> requests. If it happens only with localhost requests, perhaps we > Eli> could make some changes only for that case. > > Eli> Robert, any ideas or suggestions? > > The fact that it始s localhost shouldn始t matter. The code in question is > convoluted, as you well know, so figuring out what始s going on needs us > to have a good understanding of which cases trigger this > behaviour. But the evidence so far points at the handling of the > timeout. In the case of a remote host, the speedup was marginal, so I think the localhost does matter, somehow. Perhaps instrumenting wait_reading_process_output with printf's would help to understand the control flow in the case of nil and non-nil PROCESS argument?
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 08:41:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 04:41:52 2025
Received: from localhost ([127.0.0.1]:56182 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uPdVP-0006P4-P2
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 04:41:52 -0400
Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:49456)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <rpluim@HIDDEN>) id 1uPdVN-0006Oc-Lc
for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 04:41:50 -0400
Received: by mail-wr1-x42b.google.com with SMTP id
ffacd0b85a97d-3a365a6804eso394619f8f.3
for <78773 <at> debbugs.gnu.org>; Thu, 12 Jun 2025 01:41:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1749717703; x=1750322503; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:from:to:cc:subject:date:message-id
:reply-to; bh=XrJ2pQecjJn1tKoq9OI5hM0FHaF3cDox5Daf0gaOjsI=;
b=nffA8udnwjB5sshlXwdV+7zIazcQzw7Ljxje5gcCQ5UovppDA+IXw3VpEWl4mkh5LE
WE0PLnLjspNGYdzCMqTmbKxDK+4ciBhX6bpso7t22vFPZDpxG8sZuoGFFmImWVkNc4hd
kQ8RqdoC4BDM0kA/iWHS+7CFeq0apQsTRhfNzYvHAirsLfKh3+fs0VfaliRyGoqUd1/Z
Tr9k3u646saF4b9sC3cpZ2DZqtmqTwOj8bEdcgXR4H9BLa1E83YmXzAQKbhM9eJaJJpC
WH8GbKziLjImq9nFsh5mkGo37d+qAiG6REEJ6HeA9VLNpfuCMfjktviywe4/PWDWnngy
NMoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1749717703; x=1750322503;
h=content-transfer-encoding:mime-version:message-id:date:references
:in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=XrJ2pQecjJn1tKoq9OI5hM0FHaF3cDox5Daf0gaOjsI=;
b=DU8IZQZ7fV8yZYxjuEDQVRjpehds/xOr5gpEXAd2ETUyjE7tvrr7msF6EUUo6rL0i3
EJJBoW4DbNuKM9lOJX0ViNPx7m718ClXd2Rq8kcXAbwvfrisXX5vah3VOT3bcSj8cLss
C6mGaicZijctfY7YUhWCpU9jwmBnaJKe41z5OvueS3DMrV/kzBxHhrJ7IRqUkRYOc9NV
4ZuilC+ufpPH9Aeq76jX+ynmFf/C2gXGtQRx0zTsw/Fi9MboXCYXdgl9s/r6swIaYB/W
hvYmt3Wstg+miqfxppJ2zEh2iPZ+0FVwiFz7STOrTqTAU5ubupvLzZHpcGBRBJsfJVu0
rebg==
X-Forwarded-Encrypted: i=1;
AJvYcCUjLqP00YPqaXZ3fGxkuK4RlauzOBclQXstyP4KwaGs8Zq9UIlnET5yyyLGRohNeIw+ZciS2w==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy+vza2AnE2CO30Oiv5lHw1GG5WPKDMlnAwzvlIl68w1ccv1+s0
HGd5E9X1zN4Ptal9Rpr7w41PojR9ll2NQtcxzriJg6IMonbWThhjKUcD7msiyWEF
X-Gm-Gg: ASbGncsdIZtw56Pig92KfFkg9i3GLqx49CmKDOSS20AC7+KNTl1jZlsilXmq3BkmeGT
PWG47jq9pWGL0R4u6T0P46RsaFEmKq7fRH8JsZkVgesywOAauYXB2ChGp2MiaywCyIfbAk+Nk+h
OkUXyMo3fYXcklzRT4MgElKiyDtV+rRhwNkQ2Cg0KcIrA3RraYlxVoy9eG6w+7fEFv/XAkY5J5i
N0NJC7RUDai9P1qDQEyeV0TaVVGdGQJjI0iUXc3VmjgMpnnodNwIm+NZfL63nZVEw4mg0z19J9Y
KknSL14WJWaC2tSfHSTA9dnJZCJwoY8XQTz7Y5lGGShGBAs1aQ==
X-Google-Smtp-Source: AGHT+IGFXV4fL+7jg3uacAsPFNonGQV+sNwyTu23dYDfI0ZZMtoiIsG4ShUBfGSQqsGzrpx6usq4dA==
X-Received: by 2002:a05:6000:2283:b0:3a3:7ba5:93a5 with SMTP id
ffacd0b85a97d-3a55869cd37mr5292303f8f.26.1749717703021;
Thu, 12 Jun 2025 01:41:43 -0700 (PDT)
Received: from rltb ([2a01:e0a:3f3:fb51:949a:873a:3ff3:56b6])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-3a561b65ab2sm1324278f8f.96.2025.06.12.01.41.42
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 12 Jun 2025 01:41:42 -0700 (PDT)
From: Robert Pluim <rpluim@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
low-latency connections
In-Reply-To: <8634c5h30i.fsf@HIDDEN>
References: <8734c51u0i.fsf@HIDDEN> <8634c5h30i.fsf@HIDDEN>
Date: Thu, 12 Jun 2025 10:41:41 +0200
Message-ID: <87frg59wsa.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 78773
Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN, Steven Allen <steven@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
(I dropped dick chiang from the CC=CA=BCs)
>>>>> On Thu, 12 Jun 2025 09:45:17 +0300, Eli Zaretskii <eliz@HIDDEN> said:
Eli> What happens if you leave the 1st argument of accept-process-outpu=
t at
Eli> its current nil value, but change the 2nd argument to be 0.005 ins=
tead
Eli> of 0.05 (i.e., 10 times smaller)?
That speeds it up, although not as dramatically
Eli> Also, how many other sub-processes (of any kind, not just network
Eli> processes) do you have in that session when you are testing this
Eli> issue?
The answer to that is important, since there are a couple of loops in
`wait_reading_process_output' that depend on that, and can trigger DNS
or TLS operations as a result. But I=CA=BCve just tested this in 'emacs -Q'
with zero processes, and I see the speedup.
>> **Historical context**
>>=20
>> `url-retrieve-synchronously' was changed to wait on "nil" in:
>>=20
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D49897,
>>=20
>> Motivated by this bug report:
>>=20
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D49861
>>=20
>> However, the patch in question also changed the rest of
>> `url-retrieve-synchronously' so I'm hoping the issue lies elsewhere?
Eli> Unfortunately, I doubt that we will get any useful answers to this
Eli> question. We need to understand better why asking for output from=
a
Eli> single process has such a dramatic effect in your case with localh=
ost
Eli> requests. If it happens only with localhost requests, perhaps we
Eli> could make some changes only for that case.
Eli> Robert, any ideas or suggestions?
The fact that it=CA=BCs localhost shouldn=CA=BCt matter. The code in questi=
on is
convoluted, as you well know, so figuring out what=CA=BCs going on needs us
to have a good understanding of which cases trigger this
behaviour. But the evidence so far points at the handling of the
timeout.
Robert
--=20
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.Received: (at 78773) by debbugs.gnu.org; 12 Jun 2025 06:45:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 02:45:31 2025 Received: from localhost ([127.0.0.1]:55503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uPbgo-0005Ht-EO for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 02:45:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47332) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1uPbgl-0004xZ-S3 for 78773 <at> debbugs.gnu.org; Thu, 12 Jun 2025 02:45: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 1uPbgf-0000Ty-Fi; Thu, 12 Jun 2025 02:45: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=6WgUHcbL6EIGgvPRIAJgGD1HhM7axmxywI0n/DySrtg=; b=Ciy08OQHewcl EYz1piHWxPv/y5HEMyceofnHi3j+5oa1lecpmxzNl/MknyZmzolSqeqQUwZkAamfUOEUeS1lNmMK8 fSbFBO8p3/pcFq31yzU29NdGFEzJLkMSFvVp8cw+O4wqBasZps7ZeXANweGkqbVBwZJQxlB3rv8FH gyGjJMcIuM5sgTFzRhsKwctT4wrTuKz3vS9Tvsmp1/68Jg+oS7W1IG0X5iodJS8SsRxcwrxR3QOrl um5Q0q3r3PTyB44Xwn5OihXkZ4xkSLr3MiljMDuLOxC79OV+HyeMZLCNHnIhKQS611M4e1NeYGAOn 7Vy0nnF5CSl7HI3q33TVOw==; Date: Thu, 12 Jun 2025 09:45:17 +0300 Message-Id: <8634c5h30i.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Steven Allen <steven@HIDDEN>, Robert Pluim <rpluim@HIDDEN> In-Reply-To: <8734c51u0i.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections References: <8734c51u0i.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 78773 Cc: 78773 <at> debbugs.gnu.org, larsi@HIDDEN, dick.r.chiang@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: Lars Ingebrigtsen <larsi@HIDDEN>, dick <dick.r.chiang@HIDDEN> > Date: Wed, 11 Jun 2025 21:08:45 -0700 > From: Steven Allen via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > **Present context:** > > I'm running into an issue in emacs-syncthing [1] where making a few > localhost network requests are taking a full second (blocking Emacs) > when they should be instantaneous. While digging into > `url-retrieve-synchronously', I found that waiting on the correct > network process instead of passing nil to `accept-process-output' made > these network requests instantaneous (although I have no idea why). See > the attached patch. > > [1]: https://github.com/KeyWeeUsr/emacs-syncthing > > To test this patch, you can: > > 1. Run a simple web server on localhost. I usually use > > python -m http.server --bind 127.0.0.1 8000 > > 2. Evaluate: (benchmark 100 '(url-retrieve-synchronously "http://127.0.0.1:8000")) > > With this patch, this form is ~16x faster on my machine. I've also > tested this against a remote machine with a ~45ms latency and found a > 1.25x speedup. > > I've confirmed that this isn't busy-waiting by modifying this code to > print a message each time it loops: it loops the same number of times > with or without my patch. > > I've confirmed that this speedup is strictly due to passing the target > process to `accept-process-output' by applying my patch then changing > JUST "proc" to "nil": > > ;; ms, so split the difference. > (accept-process-output proc 0.05)) > > to > > ;; ms, so split the difference. > (accept-process-output nil 0.05)) > > With this one change, this code goes back to being as slow as it was before. What happens if you leave the 1st argument of accept-process-output at its current nil value, but change the 2nd argument to be 0.005 instead of 0.05 (i.e., 10 times smaller)? Also, how many other sub-processes (of any kind, not just network processes) do you have in that session when you are testing this issue? > **Historical context** > > `url-retrieve-synchronously' was changed to wait on "nil" in: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49897, > > Motivated by this bug report: > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49861 > > However, the patch in question also changed the rest of > `url-retrieve-synchronously' so I'm hoping the issue lies elsewhere? Unfortunately, I doubt that we will get any useful answers to this question. We need to understand better why asking for output from a single process has such a dramatic effect in your case with localhost requests. If it happens only with localhost requests, perhaps we could make some changes only for that case. Robert, any ideas or suggestions?
bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 12 Jun 2025 04:09:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 12 00:09:24 2025
Received: from localhost ([127.0.0.1]:54799 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uPZFj-0007ME-BA
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 00:09:23 -0400
Received: from lists.gnu.org ([2001:470:142::17]:41560)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <steven@HIDDEN>)
id 1uPZFg-0007Km-3J
for submit <at> debbugs.gnu.org; Thu, 12 Jun 2025 00:09:21 -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 <steven@HIDDEN>)
id 1uPZFF-0000ZI-19
for bug-gnu-emacs@HIDDEN; Thu, 12 Jun 2025 00:08:53 -0400
Received: from fout-b1-smtp.messagingengine.com ([202.12.124.144])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <steven@HIDDEN>)
id 1uPZFB-0008GQ-GT
for bug-gnu-emacs@HIDDEN; Thu, 12 Jun 2025 00:08:52 -0400
Received: from phl-compute-05.internal (phl-compute-05.phl.internal
[10.202.2.45])
by mailfout.stl.internal (Postfix) with ESMTP id 12B261140175;
Thu, 12 Jun 2025 00:08:48 -0400 (EDT)
Received: from phl-mailfrontend-01 ([10.202.2.162])
by phl-compute-05.internal (MEProxy); Thu, 12 Jun 2025 00:08:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stebalien.com;
h=cc:cc:content-type:content-type:date:date:from:from
:in-reply-to:message-id:mime-version:reply-to:subject:subject:to
:to; s=fm3; t=1749701327; x=1749787727; bh=xCarY22GUUeg9O7eLpsAJ
MZVbSv1EAQk8gx6oifdD9c=; b=TJ2hWSEHRZ6hDbjtk5qC1tFNENvqAms5c+pmu
MLJ0HZz8I8aplng0JkkRpUEXaMIMrzzkGz2oNvSdJv5FBoAelNCsv7s7anGp1oji
lLNrcgDFhDU9a83eWSJTawcSYmsoCUwUhLJyN1yO6VBQbONI+gWCRQLRaB0th7Tj
cY76VHRaQ1CteZ3+4jpzXCqo5osfW8r0ibnx7e2EG7wwPoRyuPcPYn7mki/ioSPm
BYgYka8p3ETFDN2/Q9QUaltaMaUNhINAWlOMF2ZGlY+MmlC082FpdVQCU8gbTiMx
2Dpvz4/Q8qS9qYlMIfNy/IqAefc55bRtfjFWpXdosqJ50/gcw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:content-type:date:date
:feedback-id:feedback-id:from:from:in-reply-to:message-id
:mime-version:reply-to:subject:subject:to:to:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1749701327; x=
1749787727; bh=xCarY22GUUeg9O7eLpsAJMZVbSv1EAQk8gx6oifdD9c=; b=o
iu8vBTgFpkJrMbyWdXq3D9rXxmHa/zFNJ/NY2diELIFlErSdwIHEjzv3LgYqUWxp
HEsR/9y/9Z8fZdegKdMqmlF5xNTYvx4v7iCgJhWzJ70OiqsjH6IXD0m+0qiVq6G3
z0TX0FXoLsHqa2fCFozf4LqYAUjcqUHEj2zZYqSMBNG1NcmR89ApHsJhjc7KEd2c
eOyJHtHUKF1RgL86k0KyyirnuYhbSllqTCG6q6l8IaJkHe9d67faopMP0noA8R3O
46ZQqMMmTl7BdoUM8Eb8tHJm+doEvw6Yv11SHgZhnrST/GZSRO7Wgg9gfk8SIm8c
54uAUBYO5d/IrGHgKiuaw==
X-ME-Sender: <xms:z1JKaPHglSxv5cUb3tyNULK1B3y1nKeC9Cf-ry6yCBKSCmN9bSMuXQ>
<xme:z1JKaMVoC0ibJ7SpW_hy2EgBJHs43tiU4mRjDOClP7FkOTSckK3jyp182d8-FruRg
6HXq9vfGx-3iMhOw74>
X-ME-Received: <xmr:z1JKaBLy-E-w_7OwE1AzhFNJyDsDurVI8RdqQJj_6d9MPK7eKkleZ30ERLEft6S0gDsN1Her0hZ0ZhZnvE_uBuTWZqSn3A0>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtddugddugedtjecutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp
uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg
hnthhsucdlqddutddtmdenucfjughrpefhvfevufffkfggtgesmhdtreertddttdenucfh
rhhomhepufhtvghvvghnucetlhhlvghnuceoshhtvghvvghnsehsthgvsggrlhhivghnrd
gtohhmqeenucggtffrrghtthgvrhhnpeeftedvfeeggfekvddtvdegkeefkeeggfegveef
gfeihfdugfdvgedttdejtdehffenucffohhmrghinhepghhithhhuhgsrdgtohhmpdduvd
ejrddtrddtrddupdhgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghr
rghmpehmrghilhhfrhhomhepshhtvghvvghnsehsthgvsggrlhhivghnrdgtohhmpdhnsg
gprhgtphhtthhopeefpdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegsuhhgqdhg
nhhuqdgvmhgrtghssehgnhhurdhorhhgpdhrtghpthhtohepughitghkrdhrrdgthhhirg
hnghesghhmrghilhdrtghomhdprhgtphhtthhopehlrghrshhisehgnhhushdrohhrgh
X-ME-Proxy: <xmx:z1JKaNGp9r8bg7igF7ozibwsgLJIMK_275W0owIJA9RShuE2smcc1A>
<xmx:z1JKaFXYh1_u93BLAmQHRUyX_hw1lYTQgDMd549BFZ1bac4UXJGSvQ>
<xmx:z1JKaIMWdl4VHJpKY7Y2-nnbLtTc2OU9NlOjFXkF_8HkOg-083my6Q>
<xmx:z1JKaE3Z4h0qLcXqwTaSMCsOcqWfxnsBWm62a2CBsD7VTgrijra2uA>
<xmx:z1JKaHa0Wqx5rLFKH1EkjIaXGlvXNGoe19cFTHj5rajoZ_Y8X-7h9u12>
Feedback-ID: ie8a146a7:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
12 Jun 2025 00:08:47 -0400 (EDT)
From: Steven Allen <steven@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: [PATCH] Speedup url-retrieve-synchronously for low-latency connections
X-Debbugs-Cc:
Date: Wed, 11 Jun 2025 21:08:45 -0700
Message-ID: <8734c51u0i.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=202.12.124.144; envelope-from=steven@HIDDEN;
helo=fout-b1-smtp.messagingengine.com
X-Spam_score_int: -15
X-Spam_score: -1.6
X-Spam_bar: -
X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_LOW=-0.7,
RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001,
WEIRD_PORT=0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.7 (/)
X-Debbugs-Envelope-To: submit
Cc: Lars Ingebrigtsen <larsi@HIDDEN>, dick <dick.r.chiang@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: -0.3 (/)
--=-=-=
Content-Type: text/plain
Tags: patch
**Present context:**
I'm running into an issue in emacs-syncthing [1] where making a few
localhost network requests are taking a full second (blocking Emacs)
when they should be instantaneous. While digging into
`url-retrieve-synchronously', I found that waiting on the correct
network process instead of passing nil to `accept-process-output' made
these network requests instantaneous (although I have no idea why). See
the attached patch.
[1]: https://github.com/KeyWeeUsr/emacs-syncthing
To test this patch, you can:
1. Run a simple web server on localhost. I usually use
python -m http.server --bind 127.0.0.1 8000
2. Evaluate: (benchmark 100 '(url-retrieve-synchronously "http://127.0.0.1:8000"))
With this patch, this form is ~16x faster on my machine. I've also
tested this against a remote machine with a ~45ms latency and found a
1.25x speedup.
I've confirmed that this isn't busy-waiting by modifying this code to
print a message each time it loops: it loops the same number of times
with or without my patch.
I've confirmed that this speedup is strictly due to passing the target
process to `accept-process-output' by applying my patch then changing
JUST "proc" to "nil":
;; ms, so split the difference.
(accept-process-output proc 0.05))
to
;; ms, so split the difference.
(accept-process-output nil 0.05))
With this one change, this code goes back to being as slow as it was before.
**Historical context**
`url-retrieve-synchronously' was changed to wait on "nil" in:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49897,
Motivated by this bug report:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=49861
However, the patch in question also changed the rest of
`url-retrieve-synchronously' so I'm hoping the issue lies elsewhere?
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, cairo version
1.18.4) of 2025-06-11 built on Laptop
Repository revision: 87244ef1661f9e9d7c08f65047551e8a34cd92b2
Repository branch: makepkg
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: Arch Linux
Configured using:
'configure
'CPPFLAGS=-I/run/user/1000/build/emacs-git/src/mps-git/build/include '
'LDFLAGS=-L/run/user/1000/build/emacs-git/src/mps-git/build/lib -Wl,-O1
-Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
-Wl,-z,pack-relative-relocs -flto=auto' --prefix=/usr --sysconfdir=/etc
--libexecdir=/usr/lib --localstatedir=/var --mandir=/usr/share/man
--with-gameuser=:games --with-modules --without-m17n-flt
--without-selinux --without-pop --without-gconf --disable-gc-mark-trace
--with-mps=yes --enable-link-time-optimization
--with-native-compilation=yes --with-xinput2 --with-x-toolkit=no
--without-toolkit-scroll-bars --without-xaw3d --without-gsettings
--with-cairo-xcb --without-xft --with-sound=no --with-tree-sitter
--without-gpm --without-compress-install
'--program-transform-name=s/\([ec]tags\)/\1.emacs/'
'CFLAGS=-march=native -mtune=native -O3 -pipe -fno-plt -fexceptions
-Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security
-fstack-clash-protection -fcf-protection -fomit-frame-pointer
-fno-math-errno -fno-trapping-math -fno-math-errno -fno-trapping-math
-flto=auto''
--=-=-=
Content-Type: text/patch
Content-Disposition: attachment;
filename=0001-Speedup-url-retrieve-synchronously-for-low-latency-c.patch
From 4529f63f3c55b40fd43642592cd4dc7162766c7f Mon Sep 17 00:00:00 2001
From: Steven Allen <steven@HIDDEN>
Date: Wed, 11 Jun 2025 20:19:01 -0700
Subject: [PATCH] Speedup url-retrieve-synchronously for low-latency
connections
On my machine, this provides a ~16x speedup for localhost request and a
1.28x speedup for a 50ms latency connection.
* lisp/url/url.el (url-retrieve-synchronously): Wait for output from the
target process instead of waiting for output from any process.
---
lisp/url/url.el | 23 +++++++++++++----------
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/lisp/url/url.el b/lisp/url/url.el
index 090a952cf4c..c8dc002b0ac 100644
--- a/lisp/url/url.el
+++ b/lisp/url/url.el
@@ -270,17 +270,20 @@ url-retrieve-synchronously
(kill-buffer proc-buffer))
;; Accommodate hack in commit 55d1d8b.
(setq proc-buffer redirect-buffer)))
- (when-let* ((proc (get-buffer-process proc-buffer)))
- (when (memq (process-status proc)
+ (if-let* ((proc (get-buffer-process proc-buffer)))
+ (if (memq (process-status proc)
'(closed exit signal failed))
- ;; Process sentinel vagaries occasionally cause
- ;; url-retrieve to fail calling callback.
- (unless data-buffer
- (url-debug 'retrieval "Dead process %s" url)
- (throw 'done 'exception))))
- ;; Querying over consumer internet in the US takes 100
- ;; ms, so split the difference.
- (accept-process-output nil 0.05)))
+ ;; Process sentinel vagaries occasionally cause
+ ;; url-retrieve to fail calling callback.
+ (unless data-buffer
+ (url-debug 'retrieval "Dead process %s" url)
+ (throw 'done 'exception))
+ ;; Querying over consumer internet in the US takes 100
+ ;; ms, so split the difference.
+ (accept-process-output proc 0.05))
+ ;; This case shouldn't happen but this keeps us from
+ ;; spinning and locking up Emacs if it does.
+ (accept-process-output nil 0.05))))
;; Kill the process buffer on redirects.
(when (and data-buffer
(not (eq data-buffer proc-buffer)))
--
2.49.0
--=-=-=--
Steven Allen <steven@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#78773; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.