From: Eli Zaretskii <eliz@gnu.org>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org
Subject: bug#28542: Temporary failure in name resolution while quitting emacs
Date: Wed, 02 Dec 2020 17:06:48 +0200 [thread overview]
Message-ID: <837dq0gsc7.fsf@gnu.org> (raw)
In-Reply-To: <875z5k5yks.fsf@gnus.org> (message from Lars Ingebrigtsen on Wed, 02 Dec 2020 10:47:31 +0100)
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: bshanks3@hotmail.com, 28542@debbugs.gnu.org
> Date: Wed, 02 Dec 2020 10:47:31 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > The ELisp manual says ab out kill-emacs-hook:
> >
> > Because ‘kill-emacs’ can be called in situations where user
> > interaction is impossible (e.g., when the terminal is
> > disconnected), functions on this hook should not attempt to
> > interact with the user. If you want to interact with the user when
> > Emacs is shutting down, use ‘kill-emacs-query-functions’, described
> > below.
> >
> > So I don't think we can safely ask whether to continue.
>
> I don't quite interpret it that way -- this only says that if your
> intention is to communicate with the user, then use
> `kill-emacs-query-functions'.
But your suggestion was to ask the user whether to continue -- doesn't
that qualify as "communicating with the user"?
> The current situation is that if you have an error in `kill-emacs-hook'
> (and you're running an interactive Emacs), then you can't kill Emacs at
> all. Adding a query to the user about what to do is an improvement, and
> won't regress anything.
That's true, but I don't suggest to do nothing, I was trying to find a
better way, one which would work also when there's no way to get any
answer from the user.
> > We could either use safe_run_hooks, as we do in the noninteractive
> > case (thus silently ignoring errors in this hook even if we do have a
> > means to communicate with the user), or maybe move the offending
> > function to kill-emacs-query-functions. Or try a more limited
> > solution of ensuring this particular function doesn't signal an error,
> > or catches it and returns.
>
> I'm a bit leery at doing anything automatically (either ignoring the
> error or re-running it from a different context). The hook may be, for
> instance, writing stuff to a data file and then clearing out some
> structures, and re-writing the stuff may clear the data, for instance.
>
> Only the user should be making a judgement call in the error situation
> here.
Then perhaps waiting for the response for some finite time would cover
the cases where the user cannot answer the question?
> >> /* Fsignal calls emacs_abort () if it sees that waiting_for_input is
> >> set. */
> >> waiting_for_input = 0;
> >> if (noninteractive)
> >> safe_run_hooks (Qkill_emacs_hook);
> >> else
> >> run_hook (Qkill_emacs_hook);
> >>
> >> Is this bit done from the C level because of that waiting_for_input
> >> setting? And... I don't understand the comment -- the `error' (which
> >> calls signal?) doesn't abort Emacs? Anybody?
> >
> > I think the comment has this exact scenario in mind: if we don't make
> > sure waiting_for_input is zero, and the hook just happens to signal an
> > error, Emacs will dump core.
>
> Oh, I interpreted it the opposite way -- that "waiting_for_input = 0" is
> setting it. To zero. But it means "isn't cleared"?
Yes, setting to zero is "resetting". The abort happens if the value
is non-zero.
next prev parent reply other threads:[~2020-12-02 15:06 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-21 17:13 bug#28542: Temporary failure in name resolution while quitting emacs Baylis Shanks
2020-11-30 10:53 ` Lars Ingebrigtsen
2020-11-30 16:21 ` Eli Zaretskii
2020-12-02 9:47 ` Lars Ingebrigtsen
2020-12-02 15:06 ` Eli Zaretskii [this message]
2020-12-03 8:47 ` Lars Ingebrigtsen
2020-12-03 15:16 ` Eli Zaretskii
2020-12-04 9:34 ` Lars Ingebrigtsen
2020-12-04 9:50 ` Robert Pluim
2020-12-04 18:41 ` Glenn Morris
2020-12-06 12:53 ` Lars Ingebrigtsen
2020-12-04 11:42 ` Eli Zaretskii
2020-12-06 12:50 ` Lars Ingebrigtsen
2020-12-06 19:17 ` Eli Zaretskii
2020-12-07 14:43 ` Lars Ingebrigtsen
2020-12-07 16:01 ` Eli Zaretskii
2020-12-07 16:16 ` Lars Ingebrigtsen
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=837dq0gsc7.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=28542@debbugs.gnu.org \
--cc=bshanks3@hotmail.com \
--cc=larsi@gnus.org \
/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).