bug-gnu-emacs
[Top][All Lists]
Advanced

[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 13:25:36 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0a1

On 05.04.2019 09:14, Eli Zaretskii wrote:
Cc: address@hidden
From: Dmitry Gutov <address@hidden>
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)? And what happens if the function is interrupted before url-http-debug has had a chance to be called? Or what if it's interrupted by a different signal than 'quit'? Or what if it's interrupted by a symbol being thrown, set up by while-no-input?

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

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.

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

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?





reply via email to

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