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

From: Eli Zaretskii <[email-masked]>
Date: Sat, 14 Jun 2025 14:45:02 +0300

> From: Robert Pluim <[email-masked]>
> Cc: [email-masked],  [email-masked],  [email-masked]
> Date: Fri, 13 Jun 2025 13:59:40 +0200
> 
> >>>>> On Fri, 13 Jun 2025 13:48:08 +0300, Eli Zaretskii <[email-masked]> 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.