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

Previous Next

Full log

Message #26 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: Thu, 12 Jun 2025 12:20:30 -0700

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

>> From: Steven Allen <steven <at> stebalien.com>
>> Cc: 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
>> 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.

Previous Next

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