From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ami Fischman" Newsgroups: gmane.emacs.devel Subject: poor handling of multiple C-g with multi-tty (apparent hangs) Date: Sun, 10 Aug 2008 23:14:21 -0700 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_65924_14977680.1218435261367" X-Trace: ger.gmane.org 1218472167 18085 80.91.229.12 (11 Aug 2008 16:29:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Aug 2008 16:29:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 11 18:30:19 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KSaHh-00055w-2t for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2008 18:30:17 +0200 Original-Received: from localhost ([127.0.0.1]:42950 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSaGl-0006AG-2A for ged-emacs-devel@m.gmane.org; Mon, 11 Aug 2008 12:29:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KSQfg-0001IJ-28 for emacs-devel@gnu.org; Mon, 11 Aug 2008 02:14:24 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KSQff-0001Go-2K for emacs-devel@gnu.org; Mon, 11 Aug 2008 02:14:23 -0400 Original-Received: from [199.232.76.173] (port=58551 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KSQfe-0001GX-Qg for emacs-devel@gnu.org; Mon, 11 Aug 2008 02:14:22 -0400 Original-Received: from wr-out-0506.google.com ([64.233.184.231]:55685) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KSQfe-0005KS-Sr for emacs-devel@gnu.org; Mon, 11 Aug 2008 02:14:23 -0400 Original-Received: by wr-out-0506.google.com with SMTP id c30so1466667wra.14 for ; Sun, 10 Aug 2008 23:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:x-google-sender-auth; bh=lFYrucuma7whsx23SjNQAZVse+SFhu3t9vPVujxE6yI=; b=aw70DyhiovxnC9C27fcOodH7FAnjYdc3UxvxAVHmgVx1CnKN+BteaGTQ3WApK9GGqs xguPJ5XBPGOlycxfM8XhjrdGReydJfqe/EltZLUyo38EpLB8VXQ9kyIj/01lZykmJK04 NGrOMK9lSb70yzu8s4jWBmpAYiolpyeTydBA4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :x-google-sender-auth; b=konsQITr4MZDbCPxdmPSUwB8bi4qX0PMDkkTx1vbzLlmuNTLTn3tQzNalVEL3qg2Fj 1cl/Eekj8tZW7d1lniVzdRLkY53JZbe+z3dNnRCmQk1syHxLQPsoPEYeQ78TgSukxZQC CfmDSdofsXQgMCa6IoXoSMWxeGoQQyQPptiSE= Original-Received: by 10.90.115.17 with SMTP id n17mr6614407agc.75.1218435261387; Sun, 10 Aug 2008 23:14:21 -0700 (PDT) Original-Received: by 10.90.101.14 with HTTP; Sun, 10 Aug 2008 23:14:21 -0700 (PDT) X-Google-Sender-Auth: d4ea4f31d13159d1 X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) X-Mailman-Approved-At: Mon, 11 Aug 2008 12:28:55 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:102288 Archived-At: ------=_Part_65924_14977680.1218435261367 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 ------=_Part_65924_14977680.1218435261367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
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
------=_Part_65924_14977680.1218435261367--