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

[Eli Zaretskii]

> Cc: 34763@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 8 Apr 2019 19:42:04 +0300
> 
> > 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?

Using delete-process would take care of that.  The sentinel will run,
of course, but I see no reason to worry about that.

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

I think so, yes.

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

Depends on how the cleanup code will be written.  It can be written
such that it works regardless where the interruption happens.

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

A bug, then?

> >> 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'd also be a bug, IMO.  We can expect bugs to behave abnormally.

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

Is it related in any way with the outstanding connections being
completed/closed?  What does netstat show?

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

Yes.

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

A simple C-g should theoretically take handle that carefully.

> I wish somebody who knows URL's code could comment on that.

Seconded.

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

Yes, this part is better left to the cleanup we do in C.