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

Previous Next

Full log

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

From: Steven Allen <steven <at> stebalien.com>
To: Eli Zaretskii <eliz <at> gnu.org>
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 11:23:58 -0700

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.

In that case, `accept-process-output' will process output for those
other processes as usual (calling filters/sentinels, etc.) but won't
return call until we have data that's relevant to this call to
`url-retrieve-synchronously'. We haven't set JUST-THIS-ONE in this call
to `accept-process-output' so we won't simply *ignore* all other process
output.

To be clear, calling `accept-process-output' with a nil process is the
exception, not the norm (8 out of 105 call sites).

Previous Next

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