[Emacs-diffs] /srv/bzr/emacs/emacs-23 r100146: Print informative error message when aborting on GTK disconnect.

[Chong Yidong]

------------------------------------------------------------
revno: 100146
committer: Chong Yidong <address@hidden>
branch nick: emacs-23
timestamp: Sat 2010-10-30 23:33:56 -0400
message:
  Print informative error message when aborting on GTK disconnect.
  
  * xterm.c (x_connection_closed): Print informative error message
  when aborting on GTK.  This requires using shut_down_emacs
  directly instead of Fkill_emacs.
modified:
  src/ChangeLog
  src/xterm.c

=== modified file 'src/ChangeLog'
--- a/src/ChangeLog     2010-10-25 11:46:21 +0000
+++ b/src/ChangeLog     2010-10-31 03:33:56 +0000
@@ -1,3 +1,9 @@
+2010-10-31  Chong Yidong  <address@hidden>
+
+       * xterm.c (x_connection_closed): Print informative error message
+       when aborting on GTK.  This requires using shut_down_emacs
+       directly instead of Fkill_emacs.
+
 2010-10-25  Michael Albinus  <address@hidden>
 
        * dbusbind.c (Fdbus_call_method_asynchronously)

=== modified file 'src/xterm.c'
--- a/src/xterm.c       2010-10-25 16:08:27 +0000
+++ b/src/xterm.c       2010-10-31 03:33:56 +0000
@@ -7882,48 +7882,44 @@
        delete_frame (frame, Qnoelisp);
       }
 
-  /* We have to close the display to inform Xt that it doesn't
-     exist anymore.  If we don't, Xt will continue to wait for
-     events from the display.  As a consequence, a sequence of
-
-     M-x make-frame-on-display RET :1 RET
-     ...kill the new frame, so that we get an IO error...
-     M-x make-frame-on-display RET :1 RET
-
-     will indefinitely wait in Xt for events for display `:1', opened
-     in the first call to make-frame-on-display.
-
-     Closing the display is reported to lead to a bus error on
-     OpenWindows in certain situations.  I suspect that is a bug
-     in OpenWindows.  I don't know how to circumvent it here.  */
-
+  /* If DPYINFO is null, this means we didn't open the display in the
+     first place, so don't try to close it.  */
   if (dpyinfo)
     {
 #ifdef USE_X_TOOLKIT
-      /* If DPYINFO is null, this means we didn't open the display
-        in the first place, so don't try to close it.  */
-      {
-       extern void (*fatal_error_signal_hook) P_ ((void));
-       fatal_error_signal_hook = x_fatal_error_signal;
-       XtCloseDisplay (dpy);
-       fatal_error_signal_hook = NULL;
-      }
-#endif
+      /* We have to close the display to inform Xt that it doesn't
+        exist anymore.  If we don't, Xt will continue to wait for
+        events from the display.  As a consequence, a sequence of
+
+        M-x make-frame-on-display RET :1 RET
+        ...kill the new frame, so that we get an IO error...
+        M-x make-frame-on-display RET :1 RET
+
+        will indefinitely wait in Xt for events for display `:1',
+        opened in the first call to make-frame-on-display.
+
+        Closing the display is reported to lead to a bus error on
+        OpenWindows in certain situations.  I suspect that is a bug
+        in OpenWindows.  I don't know how to circumvent it here.  */
+      extern void (*fatal_error_signal_hook) P_ ((void));
+      fatal_error_signal_hook = x_fatal_error_signal;
+      XtCloseDisplay (dpy);
+      fatal_error_signal_hook = NULL;
+#endif /* USE_X_TOOLKIT */
 
 #ifdef USE_GTK
-      /* There is a long-standing bug in GTK that prevents the GTK
-        main loop from recovering gracefully from disconnects
-        (https://bugzilla.gnome.org/show_bug.cgi?id=85715).  Among
-        other problems, this gives rise to a stream of Glib error
-        messages that, in one incident, filled up a user's hard disk
-        (http://lists.gnu.org/archive/html/emacs-devel/2010-10/msg00927.html).
-        So, kill Emacs unconditionally if the display is closed.  */
-      {
-       fprintf (stderr, "%s\n", error_msg);
-       Fkill_emacs (make_number (70));
-       abort ();  /* NOTREACHED */
-      }
-#endif
+      /* A long-standing GTK bug prevents proper disconnect handling
+        (https://bugzilla.gnome.org/show_bug.cgi?id=85715).  Once,
+        the resulting Glib error message loop filled a user's disk.
+        To avoid this, kill Emacs unconditionally on disconnect.  */
+      shut_down_emacs (0, 0, Qnil);
+      fprintf (stderr, "%s\n\
+When compiled with GTK, Emacs cannot recover from X disconnects.\n\
+This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715\n\
+For details, see etc/PROBLEMS.\n",
+              error_msg);
+      abort ();
+#endif /* USE_GTK */
 
       /* Indicate that this display is dead.  */
       dpyinfo->display = 0;