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: Mon, 8 Apr 2019 13:25:36 +0300
> 
> On 05.04.2019 09:14, Eli Zaretskii wrote:
> >> Cc: 34763@debbugs.gnu.org
> >> From: Dmitry Gutov <dgutov@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.
> 
> I think this patch makes clear at least one problem: the cleanup in case 
> of a quit is spread apart different functions, which isn't good for 
> reliability.
> 
> E.g. why doesn't url-http-debug also kill the process (but 
> url-retrieve-synchronously does)?

After installing the patch, I think we should indeed try adding code
to kill the process.  That's why I asked you to try that manually
first: to see if doing that will have some positive effect.

> And what happens if the function is interrupted before
> url-http-debug has had a chance to be called?

Not sure why you are bothered by that.  Why would we need to handle
this situation differently from the others?

> Or what if it's interrupted by a different signal than 'quit'?

That's a different issue: in general Emacs retries the calls
interrupted by signals internally.

> Or what if it's interrupted by a symbol being thrown, set up by
> while-no-input?

It shouldn't, that's what the change I proposed does, doesn't it?

> > 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?
> 
> It kind of does. Killing all processes, by itself, doesn't change things.
> 
> But if I also wait the aforementioned 10 minutes, transfers are fast 
> once again (until I repeat the reproduction scenario).

Hmmm... now I'm confused: originally you said something different
about those 10 minutes:

> Bad:
> 
> 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.

Now you seem to say that after 10-min wait the problems do go away?

> > 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.
> 
> Err, what "function that reads from a process"? If the call is 
> asynchronous, chance is, the caller will use the continuation-passing style.

In Emacs, "continuation-passing" means setting up a process filter,
right?  And the process filter does read from the process, right?  My
point was that being interruptible by C-g is implemented in the low
level code used by both accept-process-output and reading process
output that is fed to a filter.

> Anyway, I was referring to something else: the comment in url-http-debug 
> mentions (IIUC) that the url-http package might use some CPU-intensive 
> handling of the process output, url-http-debug being the sole quick 
> escape hatch (by the virtue of it signaling an error).

Wouldn't that be a bug of the code which does that processing?
Background processing shouldn't hog the CPU, because that makes Emacs
unresponsive.

> And apparently it can be called called in contexts where inhibit-quit is 
> non-nil, or else (eq quit-flag t) would never manage to evaluate to 
> true, right?

No, quit-flag could be non-nil because we don't magically test for it
everywhere, only in some strategic places.  If your Lisp takes a long
time to get to one of those places, it might see quit-flag non-nil at
some point.