Subject: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections

From: Steven Allen <[email-masked]>
Date: Sat, 14 Jun 2025 11:23:58 -0700

Eli Zaretskii <[email-masked]> writes:

>> From: Steven Allen <[email-masked]>
>> Cc: [email-masked], [email-masked], [email-masked]
>> Date: Sat, 14 Jun 2025 09:25:40 -0700
>>
>> Eli Zaretskii <[email-masked]> 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).