Re: Functions in kill-emacs-hook aren't run if emacs gets killed with SIGTERM

[Stefan Monnier]

>> I don't know what you mean by "interrupt code in dangerous state".
>> AFAIK, the only difference between SIGTERM and SIGUSRn is that SIGTERM
>> has a clear intention "please exit now", whereas the other ones's
>> intention is user-specified.
> Right, and that's what I meant: SIGTERM usually causes an exit, while
> SIGUSR can set a flag and do its thing later.

It's common for SIGTERM to delay the exit a little bit.
It usually affords to do some cleanup (e.g. we perform autosaves).

>> > The fact that SIGTERM in this case is a programmed means to stop Emacs
>> > does not mean it's the only use case where SIGTERM is delivered
>> > to Emacs.
>> 
>> Definitely, but in all cases I can think of, running kill-emacs-hook is
>> a good idea.  This assumes that the functions placed on kill-emacs-hook
>> follow the recommendation of the docstring:
>> 
>> Since `kill-emacs' may be invoked when the terminal is disconnected
>> (or in other similar situations), functions placed on this hook
>> should not expect to be able to interact with the user.

> I'm more worried by the possibility that they run Lisp code when Emacs
> is in unstable state.

The only sane way to implement it is via an event, just like SIGUSRn, so
I don't see why there would be such a risk.  The risk would rather be
the opposite: that by delaying execution to a safe time, we may delay it
indefinitely.

>> Maybe another option is to first perform the autosaves (like
>> shut_down_emacs does), and then run a hook.
> I'm not sure this is enough.  We may need to defer exiting until it is
> safe to call Lisp code.

I'm sure I understand what you mean by "enough", because I'm not sure
what you think is necessary.  To me what is necessary is:
1 - don't lose data.
2 - exit reasonably promptly.
So doing the autosaves before running the hook should make sure
1 is preserved.  But running the hook may indeed make us lose 2.
Is that what you meant by "not enough"?

To keep number 2, we could schedule a SIGALRM so as to forcefully exit
after a timeout, in case running the hook doesn't happen quickly enough.


        Stefan