GNU bug report logs - #71295
29.3; url-retrieve-synchronously does not timeout if initial connection hangs

Previous Next

Package: emacs;

Reported by: "Aaron Zeng" <z <at> bcc32.com>

Date: Fri, 31 May 2024 16:23:02 UTC

Severity: normal

Found in version 29.3

Full log


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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: z <at> bcc32.com, 71295 <at> debbugs.gnu.org, azeng <at> janestreet.com
Subject: Re: bug#71295: 29.3; url-retrieve-synchronously does not timeout if
 initial connection hangs
Date: Sat, 08 Jun 2024 09:08:39 +0300
> Date: Sat, 8 Jun 2024 00:32:44 +0300
> Cc: z <at> bcc32.com, 71295 <at> debbugs.gnu.org, azeng <at> janestreet.com
> From: Dmitry Gutov <dmitry <at> gutov.dev>
> 
> On 07/06/2024 09:20, Eli Zaretskii wrote:
> >> Date: Thu, 6 Jun 2024 23:41:39 +0300
> >> Cc:71295 <at> debbugs.gnu.org,azeng <at> janestreet.com
> >> From: Dmitry Gutov<dmitry <at> gutov.dev>
> >>
> >> It seems like a leaky abstraction (the caller has to be aware that what
> >> happens under the covers is done in several steps, and the timeout only
> >> applies to subsequent ones).
> >>
> >> If we could change the implementation to a more intuitive behavior, that
> >> would be a win, I think. Can somebody think of adverse effects?
> > Do you have a patch to consider?
> 
> This seems to work:
> 
> diff --git a/lisp/url/url.el b/lisp/url/url.el
> index dea251b453b..3b4021ceca8 100644
> --- a/lisp/url/url.el
> +++ b/lisp/url/url.el
> @@ -235,7 +235,7 @@ url-retrieve-synchronously
>   TIMEOUT is passed, it should be a number that says (in seconds)
>   how long to wait for a response before giving up."
>     (url-do-setup)
> -  (let* (url-asynchronous
> +  (let* ((url-asynchronous t)
>            data-buffer
>            (callback (lambda (&rest _args)
>                        (setq data-buffer (current-buffer))

Fine by me to install this on master, but please add there a comment
explaining why we do that disregarding the "synchronously" part of the
API's name.

Did you consider binding url-asynchronous non-nil only if TIMEOUT is
omitted or nil?  That could be even better, since the risk of breaking
something is lower, and OTOH if TIMEOUT is not passed, the original
problem does not exist and waiting "forever" is justified.  WDYT?




This bug report was last modified 1 year and 12 days ago.

Previous Next


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