From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: 34763@debbugs.gnu.org
Subject: bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function
Date: Mon, 08 Apr 2019 18:20:08 +0300 [thread overview]
Message-ID: <837ec48qxj.fsf@gnu.org> (raw)
In-Reply-To: <5110bc00-c1e3-0fd3-2a4d-8f1293c80ca5@yandex.ru> (message from Dmitry Gutov on Mon, 8 Apr 2019 13:25:36 +0300)
> Cc: 34763@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 8 Apr 2019 13:25:36 +0300
>
> 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)?
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.
> 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?
> 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.
> Or what if it's interrupted by a symbol being thrown, set up by
> while-no-input?
It shouldn't, that's what the change I proposed does, doesn't it?
> > 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:
> Bad:
>
> 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?
> > 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.
In Emacs, "continuation-passing" means setting up a process filter,
right? 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.
> 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
unresponsive.
> 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.
next prev parent reply other threads:[~2019-04-08 15:20 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-05 21:34 bug#34763: 27.0.50; url-retrieve-synchronously misbehaves inside eldoc-documentation-function Dmitry Gutov
2019-03-11 0:18 ` Dmitry Gutov
2019-03-11 14:30 ` Eli Zaretskii
2019-03-12 9:08 ` Dmitry Gutov
2019-03-12 15:02 ` Dmitry Gutov
2019-03-12 17:18 ` Eli Zaretskii
2019-03-12 17:44 ` Dmitry Gutov
2019-03-12 18:00 ` Eli Zaretskii
2019-03-12 20:05 ` Dmitry Gutov
2019-03-13 16:49 ` Eli Zaretskii
2019-03-15 14:24 ` Dmitry Gutov
2019-03-15 15:47 ` Eli Zaretskii
2019-03-15 16:07 ` Dmitry Gutov
2019-03-15 14:29 ` Dmitry Gutov
2019-03-15 15:49 ` Eli Zaretskii
2019-04-03 23:37 ` Dmitry Gutov
2019-04-04 13:04 ` Eli Zaretskii
2019-04-04 13:29 ` Dmitry Gutov
2019-04-04 14:36 ` Eli Zaretskii
2019-04-05 0:29 ` Dmitry Gutov
2019-04-05 6:14 ` Eli Zaretskii
2019-04-08 10:25 ` Dmitry Gutov
2019-04-08 15:20 ` Eli Zaretskii [this message]
2019-04-08 16:42 ` Dmitry Gutov
2019-04-08 17:13 ` Eli Zaretskii
2019-04-09 0:48 ` Dmitry Gutov
2019-04-09 6:34 ` Eli Zaretskii
2019-04-10 1:44 ` Dmitry Gutov
2019-04-10 15:46 ` Eli Zaretskii
2019-04-11 1:03 ` Dmitry Gutov
2019-04-11 7:59 ` Andreas Schwab
2019-04-11 13:08 ` Dmitry Gutov
2019-04-11 15:08 ` Dmitry Gutov
2019-04-11 16:22 ` Eli Zaretskii
2019-04-11 16:31 ` Dmitry Gutov
2019-04-13 0:44 ` Dmitry Gutov
2019-05-15 5:16 ` Lars Ingebrigtsen
2019-05-21 1:02 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=837ec48qxj.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=34763@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).