|
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: 34763@debbugs.gnu.org From: Dmitry Gutov <dgutov@yandex.ru> 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?
[Prev in Thread] | Current Thread | [Next in Thread] |