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

Previous Next

Package: emacs;

Reported by: Steven Allen <steven <at> stebalien.com>

Date: Thu, 12 Jun 2025 04:10:02 UTC

Severity: normal

Tags: patch

Full log


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

From: Steven Allen <steven <at> stebalien.com>
To: Robert Pluim <rpluim <at> gmail.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 78773 <at> debbugs.gnu.org, larsi <at> gnus.org
Subject: Re: bug#78773: [PATCH] Speedup url-retrieve-synchronously for
 low-latency connections
Date: Fri, 13 Jun 2025 07:50:59 -0700
Robert Pluim <rpluim <at> gmail.com> writes:

>>>>>> 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.
>
> But I can始t detect any difference in Steven始s test case, so maybe we
> let sleeping pselect始s lie.

I think this patch will cause us to the final drain loop when waiting on
a single connection. It's probably fine, but I assume this drain loop
existed for a reason?

  https://cgit.git.savannah.gnu.org/cgit/emacs.git/tree/src/process.c?h=bec823b107ef7d3b51b8e430ccab82c81bd63d24#n5525


> Robert
> -- 
> diff --git a/src/process.c b/src/process.c
> index e61ec425f7e..0119330f7fe 100644
> --- a/src/process.c
> +++ b/src/process.c
> @@ -5934,6 +5934,7 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>        channel_start
>  	= process_prioritize_lower_fds ? 0 : last_read_channel + 1;
>  
> +      bool break_now = false;
>        for (channel = channel_start, wrapped = false;
>  	   !wrapped || (channel < channel_start && channel <= max_desc);
>  	   channel++)
> @@ -5975,8 +5976,11 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>  	      if (nread > 0)
>  		{
>  		  /* Vacuum up any leftovers without waiting.  */
> -		  if (wait_proc == XPROCESS (proc))
> -		    wait = MINIMUM;
> +		  if (!wait_proc || wait_proc == XPROCESS (proc))
> +		    {
> +		      wait = MINIMUM;
> +		      break_now = true;
> +		    }
>  		  /* Since read_process_output can run a filter,
>  		     which can call accept-process-output,
>  		     don't try to read from any other processes
> @@ -6119,6 +6123,8 @@ wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd,
>  		}
>  	    }
>  	}			/* End for each file descriptor.  */
> +      if (break_now)		/* Don't rerun select.  */
> +	break;
>      }				/* End while exit conditions not met.  */
>  
>    unbind_to (count, Qnil);




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.