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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Steven Allen <steven <at> stebalien.com>
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 21:28:52 +0300

> 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 11:23:58 -0700
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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).

That might be, but in this particular case we changed the call to give
it the nil argument for a reason, and it will be hard to convince me
to go back on that decision.  So I suggest to explore other ways of
solving this first.

Previous Next

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