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

Previous Next

Full log

Message #54 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: Mon, 07 Dec 2020 18:01:02 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: bshanks3 <at> hotmail.com,  28542 <at> debbugs.gnu.org
> Date: Mon, 07 Dec 2020 15:43:43 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > 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?
> 
> It is somewhat special-purpose; yes.  On the other hand, implementing it
> in Lisp is a lot easier, and I guess I could envision people actually
> using it for other things, too?  So I just put it in subr.el.  (But I
> did not document it in the manual, because it does not seem to warrant
> that.)

Beware: calling Lisp when we are about to crash due to a fatal signal
could cause more problems than it solves.

> > 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.
> 
> I'm not quite sure I'm reading this paragraph right -- I'm not sure what
> "that" in "shouldn't be part of that" refers to here.  :-)

"That" refers to the function you wanted to provide.

Previous Next

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