GNU bug report logs - #28542
Temporary failure in name resolution while quitting emacs

Previous Next

Full log

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: bshanks3 <at> hotmail.com, 28542 <at> debbugs.gnu.org
Subject: Re: bug#28542: Temporary failure in name resolution while quitting
 emacs
Date: Wed, 02 Dec 2020 17:06:48 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: bshanks3 <at> hotmail.com,  28542 <at> debbugs.gnu.org
> Date: Wed, 02 Dec 2020 10:47:31 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

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