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

Previous Next

Full log

View this message in rfc822 format

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: bug#28542: Temporary failure in name resolution while quitting emacs
Date: Sun, 06 Dec 2020 21:17:55 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: bshanks3 <at> hotmail.com,  28542 <at> debbugs.gnu.org
> Date: Sun, 06 Dec 2020 13:50:14 +0100
> 
> Sure, a prompt with a timeout would be fine by me.
> 
> Looking at the code again:
> 
>   /* 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);
> 
> Would it make sense to create a new Lisp-level function to do the
> run-hook/prompting stuff, and call out to that?  And move the setting of
> waiting_for_input into the "then" branch?

I think it'd be good to have a run_hook_with_timeout function, yes.
Whether it should be exposed to Lisp, I'm less certain: what would be
the use case that isn't this single place?

As for zeroing waiting_for_input: it's almost certainly shouldn't be
part of that, since it should always be zero when Emacs signals an
error.  We do this here because this might be exiting due to a fatal
signal, in which case all bets are off, and we should better be safe
than sorry.

Previous Next

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