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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Jun 2025 19:33:57 +0300

> From: Steven Allen <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked]
> Date: Sat, 14 Jun 2025 09:15:00 -0700
> 
> Eli Zaretskii <[email-masked]> writes:
> 
> > We wait the second time because there could be more input, so I don't
> > see how this could be wrong in general.  I also don't quite see the
> > "gotcha!" in your analysis below:
> 
> There is no available input. There might be more input in 10ms

That's what I meant by "there could be more input".

> My understanding is that `accept-process-output' is supposed to return
> immediately when output has been read BOTH when PROCESS is nil and when
> it is non-nil.

That's true, but wait_reading_process_output is called not just by
accept-process-output, it is called by several other callers, and in
that case it is not necessarily true that we need to exit immediately
upon the first available channel.  Keep in mind that reading from a
subprocess also invokes a filter function, if there is one, so it
might make sense in some cases to read from more than one source,
perhaps even from all of the ones that have output ready to be read.

> Looking at the history, it looks like the code in question was changed
> in bug#20978. However, from what I can tell, we should only apply
> adaptive read buffering when `process-adaptive-read-buffering' is
> non-nil. I think we may need to change the check in question to:
> 
> 		  if (!process_output_skip && (!wait_proc || wait_proc == XPROCESS (proc)))
> 		    wait = MINIMUM;

That could indeed fly, but process-adaptive-read-buffering is non-nil
by default.  Does url set it to nil?

In any case, I think the addition of process-adaptive-read-buffering
test should only affect the case when wait_proc is zero.