changeset 83454:845a93c68e9a

Fix C-g during `make-network-process'. (Reported by Mark Plaksin.) * src/process.c (Fmake_network_process): Don't unrequest_sigio on modern systems. * src/keyboard.c (Fset_input_interrupt_mode): Cosmetic change. * src/sysdep.c (request_sigio): Make it a no-op if noninteractive. (unrequest_sigio): Make it a no-op if noninteractive. git-archimport-id: [e-mail]--2004/emacs--multi-tty--0--patch-494

--- a/README.multi-tty	Fri Jan 06 16:13:05 2006 +0000
+++ b/README.multi-tty	Wed Jan 11 14:51:51 2006 +0000
@@ -401,6 +401,16 @@
 THINGS TO DO
 ------------
 
+** Understand how `quit_throw_to_read_char' works, and fix any bugs
+   that come to light.
+
+** Replace wrong_kboard_jmpbuf with a special return value of
+   read_char.  It is absurd that we use setjmp/longjmp just to return
+   to the immediate caller.
+
+** See if getcjmp can be eliminated somehow.  Why does Emacs allow
+   asynchronous input processing while it's reading input anyway?
+
 ** `delete-frame' events are handled by `special-event-map'
    immediately when read by `read_char'.  This is fine but it prevents
    higher-level keymaps from binding that event to get notified of the
@@ -688,15 +698,6 @@
 
 ** Do a grep on XXX and ?? for more issues.
 
-** Understand Emacs's low-level input system (it's black magic) :-)
-   What exactly does interrupt_input do?  I tried to disable it for
-   raw secondary tty support, but it does not seem to do anything
-   useful.  (Update: Look again. X unconditionally enables this, maybe
-   that's why raw terminal support is broken again.  I really do need
-   to understand input.)
-   (Update: I am starting to understand the read_key_sequence->read-char
-   ->kbd_buffer_get_event->read_avail_input->read_socket_hook path.  Yay!)
-
 ** flow-ctrl.el must be updated.
 
 ** Fix stuff_char for multi-tty.  Doesn't seem to be of high priority.
@@ -1435,6 +1436,22 @@
    kills the terminal.  There was no bug here, but I rewrote the whole
    single_kboard mess anyway.) (patch-489)
 
+-- Understand Emacs's low-level input system (it's black magic) :-)
+   What exactly does interrupt_input do?  I tried to disable it for
+   raw secondary tty support, but it does not seem to do anything
+   useful.  (Update: Look again. X unconditionally enables this, maybe
+   that's why raw terminal support is broken again.  I really do need
+   to understand input.)
+   (Update: I am starting to understand the read_key_sequence->read-char
+   ->kbd_buffer_get_event->read_avail_input->read_socket_hook path.  Yay!)
+
+   (Update: OK, it all seems so easy now (NOT).  Input could be done
+   synchronously (with wait_reading_process_input), or asynchronously
+   by SIGIO or polling (SIGALRM).  C-g either sets the Vquit_flag,
+   signals a 'quit condition (when immediate_quit), or throws to
+   `getcjmp' when Emacs was waiting for input when the C-g event
+   arrived.)
+
 
 ;;; arch-tag: 8da1619e-2e79-41a8-9ac9-a0485daad17d
 

--- a/src/keyboard.c	Fri Jan 06 16:13:05 2006 +0000
+++ b/src/keyboard.c	Wed Jan 11 14:51:51 2006 +0000
@@ -10741,11 +10741,8 @@
   int new_interrupt_input;
 #ifdef SIGIO
 /* Note SIGIO has been undef'd if FIONREAD is missing.  */
-  if (0
 #ifdef HAVE_X_WINDOWS
-      || x_display_list != NULL
-#endif
-      )
+  if (x_display_list != NULL)
     {
       /* When using X, don't give the user a real choice,
 	 because we haven't implemented the mechanisms to support it.  */
@@ -10756,6 +10753,7 @@
 #endif /* NO_SOCK_SIGIO */
     }
   else
+#endif
     new_interrupt_input = !NILP (interrupt);
 #else /* not SIGIO */
   new_interrupt_input = 0;
@@ -10787,7 +10785,7 @@
     }
   return Qnil;
 }
-  
+
 DEFUN ("set-output-flow-control", Fset_output_flow_control, Sset_output_flow_control, 1, 2, 0,
        doc: /* Enable or disable ^S/^Q flow control for output to TERMINAL.
 If FLOW is non-nil, flow control is enabled and you cannot use C-s or

--- a/src/process.c	Fri Jan 06 16:13:05 2006 +0000
+++ b/src/process.c	Wed Jan 11 14:51:51 2006 +0000
@@ -3086,6 +3086,10 @@
 
  open_socket:
 
+#ifdef __ultrix__
+  /* Previously this was compiled unconditionally, but that seems
+     unnecessary on modern systems, and `unrequest_sigio' was a noop
+     under X anyway. --lorentey */
   /* Kernel bugs (on Ultrix at least) cause lossage (not just EINTR)
      when connect is interrupted.  So let's not let it get interrupted.
      Note we do not turn off polling, because polling is only used
@@ -3102,6 +3106,7 @@
       record_unwind_protect (unwind_request_sigio, Qnil);
       unrequest_sigio ();
     }
+#endif
 
   /* Do this in case we never enter the for-loop below.  */
   count1 = SPECPDL_INDEX ();

--- a/src/sysdep.c	Fri Jan 06 16:13:05 2006 +0000
+++ b/src/sysdep.c	Wed Jan 11 14:51:51 2006 +0000
@@ -1037,12 +1037,8 @@
 void
 request_sigio ()
 {
-  /* XXX read_socket_hook is not global anymore.  Is blocking SIGIO
-     bad under X? */
-#if 0
-  if (noninteractive || read_socket_hook)
+  if (noninteractive)
     return;
-#endif
 
 #ifdef SIGWINCH
   sigunblock (sigmask (SIGWINCH));
@@ -1055,13 +1051,14 @@
 void
 unrequest_sigio (void)
 { 
-  /* XXX read_socket_hook is not global anymore.  Is blocking SIGIO
-     bad under X? */
-#if 0
-  if (noninteractive || read_socket_hook)
+  if (noninteractive)
+    return;
+
+#if 0 /* XXX What's wrong with blocking SIGIO under X?  */
+  if (x_display_list)
     return;
 #endif
-  
+
 #ifdef SIGWINCH
   sigblock (sigmask (SIGWINCH));
 #endif