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

[Dmitry Gutov]

On 08.04.2019 18:20, Eli Zaretskii wrote:

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

OK then. But if we're killing the process, should we worry about the 
sentinel and the filter?

url-retrieve-synchronously doesn't bother to reset them, just kills the 
process. Speaking of, shouldn't that be enough for our scenario?

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

Well, if url-http-debug is never entered, its cleanup logic will never 
be executed. Shouldn't we consider that a problem as well?

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

I mean, like, interrupted by a different kind of error. Not a signal 
that's cleanly handled in Emacs's internals.

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

I mean the running code is interrupted, in general, by a symbol being 
thrown. That would also be the case of url-http-debug's cleanup never 
being run.

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

*If* I kill the running processes before doing that 10-minute wait, yes.

At least that's what I meant. But, sorry to report, repeating the same 
couple of experiments again doesn't yield the same result (killing the 
processes didn't give any measurable impact compared to not killing them 
and simply waiting).

So we seem to have two problems, yes.

Simply waiting for a some amount of time tends to get the problem 
"unstuck", though the improvement is gradual and fairly unpredictable.

> In Emacs, "continuation-passing" means setting up a process filter,
> right?

Sure, as one example.

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

Okay. But that is referring to the code that reads the output, not 
whatever CPU-intensive loops can be inside the filter function, right?

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

Well, URL is a general purpose package, not always used in the 
background. To make it suitable for background processing is the goal of 
the current bug report, isn't it?

And as for "bug of the code", I'm saying that there must be some code 
that can hog the CPU (the comment refers to it), and we might want to 
handle that carefully. I wish somebody who knows URL's code could 
comment on that.

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

I see, thank you.

It probably means that seeing non-nil quit-flag is unreliable anyway, 
though, so doing cleanup or not depending on the value of that variable 
seems unwise.