unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Dan Nicolaescu <dann@ics.uci.edu>
Cc: emacs-pretest-bug@gnu.org, hanche@math.ntnu.no, rms@gnu.org
Subject: after-delete-terminal-functions (was: 23.0.60; Emacs should survive a lost X connection)
Date: Tue, 12 Feb 2008 22:09:06 -0500	[thread overview]
Message-ID: <jwvabm58szb.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <200802100803.m1A83Eq5026472@sallyv1.ics.uci.edu> (Dan Nicolaescu's message of "Sun, 10 Feb 2008 00:03:11 -0800")

> emacs -Q -nw -f server-start

> emacsclient -c -d $DISPLAY&

> xkill 
> the emacsclient X11 frame

> then C-x C-c in the emacs -nw frame will warn about clients still being
> connected.

> Same thing when instead of using xkill, kill X11.

So I looked at the issue of letting know server.el when an X11
connection is abruptly closed as above.

I created a new event DELETE_TERMINAL_EVENT;
changed Fdelete_terminal to generate such an event;
changed x_connection_closed to call Fdelete_terminal

and ... it didn't work.  The problem is that x_connection_closed ends up
signalling an error, which flushes the input queue and hence throws away
the DELETE_TERMINAL_EVENT we just created.

So, I removed the `error' call, but this makes things worse, apparently:
Emacs then exits abruptly.  It seems that it's important to abort
execution at the end of x_connection_closed.  So I re[placed the `error'
call by a call to Fthrow.  This finally worked.

But now I wonder: is DELETE_TERMINAL_EVENT the right thing to do, or
should we use run-at-time instead?

Find attach my current attempt,


        Stefan


? src/.depend
cvs diff: Diffing src
Index: src/keyboard.c
===================================================================
RCS file: /sources/emacs/emacs/src/keyboard.c,v
retrieving revision 1.946
diff -u -r1.946 keyboard.c
--- src/keyboard.c	12 Feb 2008 04:05:29 -0000	1.946
+++ src/keyboard.c	13 Feb 2008 03:06:48 -0000
@@ -466,6 +466,7 @@
 Lisp_Object Qscroll_bar_movement;
 Lisp_Object Qswitch_frame;
 Lisp_Object Qdelete_frame;
+Lisp_Object Qdelete_terminal;
 Lisp_Object Qiconify_frame;
 Lisp_Object Qmake_frame_visible;
 Lisp_Object Qselect_window;
@@ -4195,6 +4196,11 @@
 	  kbd_fetch_ptr = event + 1;
 	}
 #endif
+      else if (event->kind == DELETE_TERMINAL_EVENT)
+	{
+	  obj = Fcons (Qdelete_terminal, Fcons (event->frame_or_window, Qnil));
+	  kbd_fetch_ptr = event + 1;
+	}
 #if defined (HAVE_X11) || defined (HAVE_NTGUI) || defined (MAC_OS)
       else if (event->kind == ICONIFY_EVENT)
 	{
@@ -11718,6 +11724,7 @@
   {&Qscroll_bar_movement, "scroll-bar-movement", &Qmouse_movement},
   {&Qswitch_frame,        "switch-frame",        &Qswitch_frame},
   {&Qdelete_frame,        "delete-frame",        &Qdelete_frame},
+  {&Qdelete_terminal,     "delete-terminal",     &Qdelete_terminal},
   {&Qiconify_frame,       "iconify-frame",       &Qiconify_frame},
   {&Qmake_frame_visible,  "make-frame-visible",  &Qmake_frame_visible},
   /* `select-window' should be handled just like `switch-frame'
Index: src/lisp.h
===================================================================
RCS file: /sources/emacs/emacs/src/lisp.h,v
retrieving revision 1.611
diff -u -r1.611 lisp.h
--- src/lisp.h	12 Feb 2008 21:35:14 -0000	1.611
+++ src/lisp.h	13 Feb 2008 03:06:49 -0000
@@ -3261,6 +3261,7 @@
 extern void fatal P_ ((const char *msgid, ...)) NO_RETURN;
 
 /* Defined in terminal.c */
+EXFUN (Fdelete_terminal, 2);
 extern void syms_of_terminal P_ ((void));
 
 #ifdef HAVE_WINDOW_SYSTEM
Index: src/puresize.h
===================================================================
RCS file: /sources/emacs/emacs/src/puresize.h,v
retrieving revision 1.104
diff -u -r1.104 puresize.h
--- src/puresize.h	1 Feb 2008 23:29:14 -0000	1.104
+++ src/puresize.h	13 Feb 2008 03:06:49 -0000
@@ -35,7 +35,7 @@
    amount of storage.  This is a lot more update-robust that defining
    BASE_PURESIZE or even PURESIZE directly.  */
 #ifndef SYSTEM_PURESIZE_EXTRA
-#define SYSTEM_PURESIZE_EXTRA 0
+#define SYSTEM_PURESIZE_EXTRA 1000000
 #endif
 
 #ifndef SITELOAD_PURESIZE_EXTRA
Index: src/termhooks.h
===================================================================
RCS file: /sources/emacs/emacs/src/termhooks.h,v
retrieving revision 1.91
diff -u -r1.91 termhooks.h
--- src/termhooks.h	8 Jan 2008 20:44:20 -0000	1.91
+++ src/termhooks.h	13 Feb 2008 03:06:49 -0000
@@ -137,6 +137,7 @@
   SELECTION_CLEAR_EVENT,	/* Another X client cleared our selection.  */
   BUFFER_SWITCH_EVENT,		/* A process filter has switched buffers.  */
   DELETE_WINDOW_EVENT,		/* An X client said "delete this window".  */
+  DELETE_TERMINAL_EVENT,        /* A terminal was deleted.  */
   MENU_BAR_EVENT,		/* An event generated by the menu bar.
 				   The frame_or_window field's cdr holds the
 				   Lisp-level event value.
Index: src/terminal.c
===================================================================
RCS file: /sources/emacs/emacs/src/terminal.c,v
retrieving revision 1.9
diff -u -r1.9 terminal.c
--- src/terminal.c	11 Feb 2008 03:51:39 -0000	1.9
+++ src/terminal.c	13 Feb 2008 03:06:49 -0000
@@ -320,6 +320,15 @@
 	error ("Attempt to delete the sole active display terminal");
     }
 
+  if (!NILP (Vrun_hooks))
+    {
+      struct input_event ie;
+      ie.kind = DELETE_TERMINAL_EVENT;
+      ie.arg = Qnil;
+      XSETTERMINAL (ie.frame_or_window, t);
+      kbd_buffer_store_event (&ie);
+    }
+
   if (t->delete_terminal_hook)
     (*t->delete_terminal_hook) (t);
   else
Index: src/xterm.c
===================================================================
RCS file: /sources/emacs/emacs/src/xterm.c,v
retrieving revision 1.975
diff -u -r1.975 xterm.c
--- src/xterm.c	10 Feb 2008 21:56:37 -0000	1.975
+++ src/xterm.c	13 Feb 2008 03:06:50 -0000
@@ -8093,10 +8093,11 @@
      OpenWindows in certain situations.  I suspect that is a bug
      in OpenWindows.  I don't know how to circumvent it here.  */
 
+  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.  */
-  if (dpyinfo)
     {
       extern void (*fatal_error_signal_hook) P_ ((void));
       fatal_error_signal_hook = x_fatal_error_signal;
@@ -8106,12 +8107,9 @@
 #endif
 
 #ifdef USE_GTK
-  if (dpyinfo)
     xg_display_close (dpyinfo->display);
 #endif
 
-  if (dpyinfo)
-    {
       /* Indicate that this display is dead.  */
       dpyinfo->display = 0;
 
@@ -8121,7 +8119,14 @@
         /* We have just closed all frames on this display. */
         abort ();
 
-      x_delete_display (dpyinfo);
+      {
+	struct terminal *t = terminal_list;
+	Lisp_Object tmp;
+	while (t && t->display_info.x != dpyinfo)
+	  t = t->next_terminal;
+	XSETTERMINAL (tmp, t);
+	Fdelete_terminal (tmp, Qnoelisp);
+      }
     }
 
   x_uncatch_errors ();
@@ -8146,7 +8151,10 @@
      error might not be the best thing to do.  I'd vote for creating an
      elisp event and stuffing it in the queue so people can bind to it via
      the global map.  --Stef  */
-  error ("%s", error_msg);
+  /* We used to throw an error, but this flushes the input_event queue,
+     on which we just put a DELETE_TERMINAL_EVENT :-(
+     error ("%s", error_msg) */
+  Fthrow (Qtop_level, Qnil);
 }
 
 /* We specifically use it before defining it, so that gcc doesn't inline it,
@@ -11812,6 +11812,10 @@
     return;
 
   BLOCK_INPUT;
+  /* When called from x_connection_closed, the display is already closed
+     and dpyinfo->display was set to 0 to indicate that.  */
+  if (dpyinfo->display)
+    {
 #ifdef USE_FONT_BACKEND
   if (! enable_font_backend)
 #endif
@@ -11834,6 +11838,7 @@
   XCloseDisplay (dpyinfo->display);
 #endif
 #endif /* ! USE_GTK */
+    }
 
   x_delete_display (dpyinfo);
   UNBLOCK_INPUT;
cvs diff: Diffing src/bitmaps
cvs diff: Diffing src/m
cvs diff: Diffing src/s




  parent reply	other threads:[~2008-02-13  3:09 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-05 14:58 23.0.60; Emacs should survive a lost X connection Harald Hanche-Olsen
2008-02-05 19:57 ` Dan Nicolaescu
2008-02-05 20:39   ` Harald Hanche-Olsen
2008-02-05 23:49   ` Dan Nicolaescu
2008-02-06 19:20     ` Richard Stallman
2008-02-06 20:07       ` Dan Nicolaescu
2008-02-08  4:16         ` Richard Stallman
2008-02-08  7:26           ` Dan Nicolaescu
2008-02-09  4:52             ` Richard Stallman
2008-02-09  5:04               ` Dan Nicolaescu
2008-02-10  3:10                 ` Stefan Monnier
2008-02-10  8:03                   ` Dan Nicolaescu
2008-02-10 20:26                     ` Stefan Monnier
2008-02-11 13:35                       ` Richard Stallman
2008-02-10 22:08                     ` Stefan Monnier
2008-02-11  5:34                       ` Dan Nicolaescu
2008-02-11 14:41                         ` Stefan Monnier
2008-02-11 17:16                           ` Dan Nicolaescu
2008-02-13  3:09                     ` Stefan Monnier [this message]
2008-02-13 22:00                       ` after-delete-terminal-functions (was: 23.0.60; Emacs should survive a lost X connection) Richard Stallman
2008-02-13 22:24                         ` after-delete-terminal-functions Stefan Monnier
2008-02-18 17:31                           ` after-delete-terminal-functions Richard Stallman
2008-03-29  3:44                             ` after-delete-terminal-functions Stefan Monnier
2008-02-10  3:20                 ` 23.0.60; Emacs should survive a lost X connection Richard Stallman
2008-02-10  8:03                   ` Dan Nicolaescu
2008-02-10 15:36                     ` Stefan Monnier
2008-02-10  8:27           ` Harald Hanche-Olsen
2008-02-10  8:58             ` Miles Bader
2008-02-10  9:34               ` Harald Hanche-Olsen
2008-02-10 13:19                 ` Miles Bader
2008-02-10 16:55                   ` Harald Hanche-Olsen
     [not found]           ` <20080208.195113.190255739.hanche@math.ntnu.no>
2008-02-10 19:04             ` Richard Stallman
2008-02-10 19:44               ` Harald Hanche-Olsen
2008-02-10 22:09                 ` Leo
2008-02-10 23:26                   ` Dan Nicolaescu
2008-02-10 23:38                     ` Leo
2008-02-11 13:34                   ` Richard Stallman
2008-02-11 23:48                     ` Leo
2008-02-11  0:17             ` Richard Stallman
2008-02-11 13:39               ` Harald Hanche-Olsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvabm58szb.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=dann@ics.uci.edu \
    --cc=emacs-pretest-bug@gnu.org \
    --cc=hanche@math.ntnu.no \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).