GNU bug report logs -
#71295
29.3; url-retrieve-synchronously does not timeout if initial connection hangs
Previous Next
Full log
Message #26 received at 71295 <at> debbugs.gnu.org (full text, mbox):
> 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.