GNU bug report logs - #34763
27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 34763 <at> debbugs.gnu.org
Subject: Re: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside
 eldoc-documentation-function
Date: Fri, 05 Apr 2019 09:14:25 +0300

> Cc: 34763 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 5 Apr 2019 03:29:55 +0300
> 
> So, I tried the patch below (did you have that change in mind exactly?), 
> and I see no adverse effects so far.

I had something like that in mind, yes.  I think this should be
installed.

> The requests still get slower after I've been typing a while, and the 
> original speed is never recovered. Even after I wait 10 minutes or so.
> 
> And this scenario still spawns lots of processes for the same host and port.

If you manually kill all processes but one, say, does the problem of
slower transfer go away?  IOW, do we have two separate problems here
or just one?

> >> 2. I wonder if there are cases where some part of the asynchronous code
> >> takes too long, where it should be allowed to be aborted by the user
> >> right away. Meaning when url-retrieve is used, not
> >> url-retrieve-synchronously.
> > 
> > I always thought that C-g aborts accept-process-output.
> 
> url-retrieve doesn't use accept-process-output.

I don't think it matters, because any function that reads from a
process will eventually call the same low-level code as
accept-process-output does, and that low-level code does abort on C-g,
AFAIR.

Previous Next

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