GNU bug report logs -
#78773
[PATCH] Speedup url-retrieve-synchronously for low-latency connections
Previous Next
Full log
Message #59 received at 78773 <at> debbugs.gnu.org (full text, mbox):
> From: Steven Allen <steven <at> stebalien.com>
> Cc: rpluim <at> gmail.com, 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Fri, 13 Jun 2025 07:45:25 -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: Thu, 12 Jun 2025 12:20:30 -0700
> >>
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >>
> >> >> 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.
> >
> > How come? What is wait_proc->status in that case?
>
> Note: this is WITH my original patch (to url.el), the one that makes it
> only wait on one process.
>
> In that case, the status is "run" the 1-2 loops through, then "exit" on
> the last loop (triggering this branch).
So your patch is only useful when the sub-process exits soon after
producing its single chunk of output, is that right?
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.