[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function
Date: Mon, 8 Apr 2019 19:42:04 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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

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:


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,

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]