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

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 78773 <at> debbugs.gnu.org, larsi <at> gnus.org, steven <at> stebalien.com
Subject: bug#78773: [PATCH] Speedup url-retrieve-synchronously for low-latency connections
Date: Sat, 14 Jun 2025 14:45:02 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: steven <at> stebalien.com,  78773 <at> debbugs.gnu.org,  larsi <at> gnus.org
> Date: Fri, 13 Jun 2025 13:59:40 +0200
> 
> >>>>> On Fri, 13 Jun 2025 13:48:08 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> Iʼm wondering why weʼre setting the timeout to zero and calling
>     >> `pselect' again, which means recomputing the wait set again, if I
>     >> havenʼt gotten lost in the twisty maze of ifʼs and global variables
>     >> 😀. Weʼve got input, why canʼt we just `break'? There might be some
>     >> work we donʼt do, but that will get done the next time
>     >> `wait_reading_process_output' is called.
> 
>     Eli> Try looking at the Git history of this code, maybe it will tell you
>     Eli> how this code evolved, and bring up past discussions and bug reports
>     Eli> which caused us to make the code as it is today.
> 
> Yes, itʼs gnarly. I think the following would be ok, and it passes the
> test case for Bug#20978.

Please explain why you think this change is okay, by talking us
through what will happen with it in the case in pint.

I generally don't like to touch this code with a 3-mile pole, and if
this means the current use case will run slowly, so be it.  So I need
a clear evidence that (a) the current code is wrong (not just
sub-optimal, but wrong), and (b) that it can never affect other cases
handled by wait_reading_process_output, of which there are a legion.

> But I canʼt detect any difference in Stevenʼs test case, so maybe we
> let sleeping pselectʼs lie.

You are saying that Stevenʼs patch also doesn't break bug#20978?  If
so, why did you post a different one?

And I don't yet understand why short-circuiting like Steven suggests
is TRT.

Previous Next

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