bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 34763@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 15 Mar 2019 16:24:44 +0200
> 
> Sounds like an external library problem, maybe?

GnuTLS?

> > If you do the same from an interactive function, not from eldoc, does
> > the problem happen there as well?
> 
> More or less. I managed to make it slower by ~20x as well.
> 
> Try this:
> 
> (defun silly-eldoc ()
>    (let ((start (time-to-seconds)))
>      (dotimes (i 10)
>        (url-retrieve-synchronously "http://www.google.com")
>        (message "try %i" i))
>      (format "done in %f" (- (time-to-seconds) start))))
> 
> (defun silly-command ()
>    (interactive)
>    (message "%s" (silly-eldoc)))
> 
> (global-set-key (kbd "C-o") #'silly-command)
> 
> Call the command a few time with C-o, it should run the timer and finish 
> with calculation how much time it took to run the requests. Now:
> 
> 1. Alternate between pressing C-o and C-g, with varying speeds.
> 
> The goal is to see
> 
>   error in process filter: Transfer interrupted!
>   error in process filter: url-http-generic-filter: Transfer interrupted!
> 
> a few times.
> 
> 2. Then see if C-o still runs to completion. If it does, and does not 
> look slow enough, repeat 1.

So it sounds like quitting in the middle of a URL retrieval leaves
some leftovers that get in the way of additional retrieval attempts.

> BUT! I have tried to reproduce this slowdown behavior with a local 
> server, and so far no luck. Ping to Google (or almost any other website) 
> is 100ms from my current location, so maybe it makes a difference.

Maybe with a local server you aren't fast enough to interrupt the
transfer before it completes?