poor handling of multiple C-g with multi-tty (apparent hangs)

["Ami Fischman" <ami@fischman.org>]

[-- Attachment #1: Type: text/plain, Size: 2861 bytes --]

Emacs has code to deal with C-g being entered while a quit is already in
progress, meant to suspend emacs and drop the user to the superior shell or
debugger (see section 59.7 Emergency Escape of the emacs info).  This is
done if emacs believes it's a good idea, which criteria includes "running in
tty mode".  Unfortunately this was never updated to work correctly with the
multi-tty patch.  As a result the following can happen:
1) Start up an "emacs -Q -nw" (tty) instance and M-x server-start RET.
2) From another shell open a tty /or/ X frame to the same emacs.
3) In the second frame eval this and immediately hit C-g while the sleep-for
is running:
(let ((inhibit-quit t)
      (quit-flag t))
  (sleep-for 10))
4) The second frame becomes unresponsive because the first (main) frame has
suspended itself and dropped back to the invoking shell.

Note that that elisp snippet is a bit extreme - in fact this behavior can be
triggered in much more innocuous ways, such as interrupting a *compilation*
at an inopportune moment.  But I don't have a simple repro recipe like the
above for the more mundane ways this can trigger.

The relevant hint is in keyboard.c:handle_interrupt() which contains:
  /* XXX This code needs to be revised for multi-tty support. */
  if (!NILP (Vquit_flag)

I work around this in my personal builds by adding an "&& 0" to the end of
the if line above, which disables the feature described by 59.7.  An
alternative workaround is to not use tty frames, or start up in a tty frame
(say inside a GNU screen session), then start at least one X frame, and kill
the original tty frame, which still allows one to have a persistent emacs
server running that can be robust to the death of an X server (as long as it
is displaying a frame on at least one other X server).

This bug is very easy to tickle accidentally; every user I've converted to
multi-tty usage patterns that uses any tty frames (either inside a screen
session for persistence or over ssh connections for speed) has run afoul of
this at some point.  As things stand I believe the feature does more harm
than good.  Since 23.1 will be the first release of emacs to contain the
multi-tty functionality (advertised in NEWS as "Improved X Window System
support") I believe it should be fixed before release.  This will require
either declaring 59.7 obsolete (intentionally removing the capability) or
the attention of someone familiar with the workings of the tty code to
resolve the XXX in the code.

FWIW I remember this happening with multi-tty years ago and repros in HEAD
builds from 20080810, 20080702, and 20070829.  Also, I believe that
resolving this correctly should resolve Dan Nicolaescu's issue reported in
emacs-devel email titled '"Auto-save? (y or n)" question when doing C-z'
with Message-ID: <200807291757.m6THv4NF010142@sallyv1.ics.uci.edu>.

Cheers,
-a

[-- Attachment #2: Type: text/html, Size: 3223 bytes --]