GNU bug report logs - #78773
[PATCH] Speedup url-retrieve-synchronously for low-latency connections

Previous Next

Full log

Message #83 received at 78773 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
Cc: 78773 <at> debbugs.gnu.org, rpluim <at> gmail.com, larsi <at> gnus.org
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
 low-latency connections
Date: Sat, 14 Jun 2025 20:04:11 +0300

> From: Steven Allen <steven <at> stebalien.com>
> Cc: rpluim <at> gmail.com, 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Sat, 14 Jun 2025 09:25:40 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What if url-retrieve was called for more than a single connection?
> > Won't your FIRST patch cause a regression in that case?
> 
> I assume you're talking about redirects here? That's the only
> multiple-process case I know about. In this case, it'll just return back
> to the top of the `url-retrieve-synchronously' loop (same as it would
> before) and wait on the next process.

No, I mean other callers of the same low-level functionality, for
example, url-retrieve.

Once again, the C function where you propose changes is used in a wide
variety of scenarios, and several clients of it could be active at the
same time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.