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

[Dmitry Gutov <dgutov@yandex.ru>]

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?