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 20:13:50 +0300 [thread overview]
Message-ID: <8336ms8lo1.fsf@gnu.org> (raw)
In-Reply-To: <cfabe8a5-8915-5357-6cf4-c3fb626af89c@yandex.ru> (message from Dmitry Gutov on Mon, 8 Apr 2019 19:42:04 +0300)
> Cc: 34763@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Mon, 8 Apr 2019 19:42:04 +0300
>
> > 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.
>
> OK then. But if we're killing the process, should we worry about the
> sentinel and the filter?
Using delete-process would take care of that. The sentinel will run,
of course, but I see no reason to worry about that.
> url-retrieve-synchronously doesn't bother to reset them, just kills the
> process. Speaking of, shouldn't that be enough for our scenario?
I think so, yes.
> >> 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?
>
> Well, if url-http-debug is never entered, its cleanup logic will never
> be executed. Shouldn't we consider that a problem as well?
Depends on how the cleanup code will be written. It can be written
such that it works regardless where the interruption happens.
> >> 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.
>
> I mean, like, interrupted by a different kind of error. Not a signal
> that's cleanly handled in Emacs's internals.
A bug, then?
> >> 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?
>
> I mean the running code is interrupted, in general, by a symbol being
> thrown.
That'd also be a bug, IMO. We can expect bugs to behave abnormally.
> *If* I kill the running processes before doing that 10-minute wait, yes.
>
> At least that's what I meant. But, sorry to report, repeating the same
> couple of experiments again doesn't yield the same result (killing the
> processes didn't give any measurable impact compared to not killing them
> and simply waiting).
>
> So we seem to have two problems, yes.
>
> Simply waiting for a some amount of time tends to get the problem
> "unstuck", though the improvement is gradual and fairly unpredictable.
Is it related in any way with the outstanding connections being
completed/closed? What does netstat show?
> > 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.
>
> Okay. But that is referring to the code that reads the output, not
> whatever CPU-intensive loops can be inside the filter function, right?
Yes.
> And as for "bug of the code", I'm saying that there must be some code
> that can hog the CPU (the comment refers to it), and we might want to
> handle that carefully.
A simple C-g should theoretically take handle that carefully.
> I wish somebody who knows URL's code could comment on that.
Seconded.
> It probably means that seeing non-nil quit-flag is unreliable anyway,
> though, so doing cleanup or not depending on the value of that variable
> seems unwise.
Yes, this part is better left to the cleanup we do in C.
next prev parent reply other threads:[~2019-04-08 17:13 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
2019-04-08 16:42 ` Dmitry Gutov
2019-04-08 17:13 ` Eli Zaretskii [this message]
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=8336ms8lo1.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).