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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Eli Zaretskii <eliz <at> gnu.org>
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: Sun, 9 Jun 2024 01:34:03 +0300

On 08/06/2024 09:08, Eli Zaretskii wrote:

>> 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?

That's a good idea. Pushed to master, with this addition and a comment.

Thinking further, though, our ability to do so bring the existence of 
this variable into question (we only change it in 
url-retrieve-synchronously).

I see it's been added as part of bug#26835 resolution, so maybe we'll 
need to re-examine that fix.

Previous Next

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