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

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: "Aaron Zeng" <z <at> bcc32.com>
Cc: 71295 <at> debbugs.gnu.org, azeng <at> janestreet.com, z <at> bcc32.com
Subject: Re: bug#71295: 29.3;
 url-retrieve-synchronously does not timeout if initial connection
 hangs
Date: Sat, 01 Jun 2024 22:38:36 +0300

> Cc: Aaron Zeng <z <at> bcc32.com>, azeng <at> janestreet.com
> Date: Fri, 31 May 2024 12:21:55 -0400
> From: "Aaron Zeng" <z <at> bcc32.com>
> 
> 1. emacs -Q
> 2. Evaluate the following in the *scratch* buffer:
> 
>    (url-retrieve-synchronously "http://google.com:81" nil nil 1)
> 
> This does not time out in one second like the TIMEOUT argument
> specifies.  Instead, in my observations it hangs for at least several
> minutes.
> 
> This attempt also doesn't work:
> 
> 
> 3. (with-timeout (1) (url-retrieve-synchronously "http://google.com:81"))
> 
> As a consequence of this, Spacemacs's attempted timeout during Emacs
> startup can take ages if one of the package archives is temporarily
> unreachable, for example due to a network firewall that is enabled at
> my site.  Spacemacs attempts to timeout after only 5 seconds, but
> instead it takes minutes.

The timeout cannot work when Emacs is stuck in a system call trying to
initiate a network connection.  That is blocking, unless you use
url-retrieve asynchronously.  The timeout starts working after the
connection is established, so it basically protects against too slow
downloading of data after the initial connection.

I think it's a bug in Spacemacs that it attempts to solve connectivity
problems this way.

Previous Next

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