14.5 Exiting

Ben’s capsule summary about expected and unexpected exits from XEmacs.

Expected exits occur when the user directs XEmacs to exit, for example by pressing the close button on the only frame in XEmacs, or by typing C-x C-c. This runs save-buffers-kill-emacs, which saves any necessary buffers, and then exits using the primitive kill-emacs.

However, unexpected exits occur in a few different ways:

• A memory access violation or other hardware-generated exception occurs. This is the worst possible problem to deal with, because the fault can occur while XEmacs is in any state whatsoever, even quite unstable ones. As a result, we need to be extremely careful what we do.
• We are using one X display (or if we’ve used more, we’ve closed the others already), and some hardware or other problem happens and suddenly we’ve lost our connection to the display. In this situation, things are not so dire as in the last one; our code itself isn’t trashed, so we can continue execution as normal, after having set things up so that we can exit at the appropriate time. Our exit still needs to be of the emergency nature; we have no displays, so any attempts to use them will fail. We simply want to auto-save (the single most important thing to do during shut-down), do minimal cleanup of stuff that has an independent existence outside of XEmacs, and exit.

Currently, both unexpected exit scenarios described above set preparing_for_armageddon to indicate that nonessential and possibly dangerous things should not be done, specifically:

• - no garbage collection.
• - no hooks are run.
• - no messages of any sort from autosaving.
• - autosaving tries harder, ignoring certain failures.
• - existing frames are not deleted.

(Also, all places that set preparing_for_armageddon also set dont_check_for_quit. This happens separately because it’s also necessary to set other variables to make absolutely sure no quitting happens.)

In the first scenario above (the access violation), we also set fatal_error_in_progress. This causes more things to not happen:

• - assertion failures do not abort.
• - printing code does not do code conversion or gettext when printing to stdout/stderr.