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

Previous Next

Full log

Message #77 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: Mon, 08 Apr 2019 20:13:50 +0300

> Cc: 34763 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> 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.

Previous Next

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