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

Previous Next

Full log

Message #68 received at 34763 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34763 <at> debbugs.gnu.org
Subject: Re: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside
 eldoc-documentation-function
Date: Mon, 8 Apr 2019 13:25:36 +0300

On 05.04.2019 09:14, Eli Zaretskii wrote:
>> Cc: 34763 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> 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?

Previous Next

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