[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected

From: David Kastrup
Subject: Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected
Date: Thu, 06 Sep 2007 22:02:20 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux)

Ted Zlatanov <address@hidden> writes:

> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <address@hidden> wrote: 
> DN> Look for a long thread in the past few weeks with the subject
> DN> "CVS HEAD fails to build on OSX 10.4"
> I looked at the thread more carefully.  Chad Brown reported a very
> specific issue exactly like the one I experienced, with the symptom
> being that keypresses are handled very slowly, but he couldn't debug
> it further because Emacs crashed.  Mitsuharu commented in the
> thread:
>> As multi-tty no longer does `FD_SET (0, &input_wait_mask)' in
>> process.c, if no `add_keyboard_wait_descriptor' calls are made,
>> then Carbon Emacs reads events from the window system only rarely
>> via polling with SIGALRM and becomes very unresponsive as reported.
> Mitsuharu, can you tell us if you think this problem can be solved
> easily?  Regardless of the state of the Carbon/Cocoa/etc ports, I'd
> like to have something that works in the CVS Emacs for MacOS users.
> Can we just reintroduce that FD_SET call, or will that break other
> things?

The respective patch says:

-------------------------------- src/process.c --------------------------------
index a129195..bd12f3e 100644
@@ -138,11 +138,11 @@ Boston, MA 02110-1301, USA.  */
 #include "charset.h"
 #include "coding.h"
 #include "process.h"
+#include "frame.h"
 #include "termhooks.h"
 #include "termopts.h"
 #include "commands.h"
 #include "keyboard.h"
-#include "frame.h"
 #include "blockinput.h"
 #include "dispextern.h"
 #include "composite.h"
@@ -328,11 +328,11 @@ extern int timers_run;
 static SELECT_TYPE input_wait_mask;
-/* Mask that excludes keyboard input descriptor (s).  */
+/* Mask that excludes keyboard input descriptor(s).  */
 static SELECT_TYPE non_keyboard_wait_mask;
-/* Mask that excludes process input descriptor (s).  */
+/* Mask that excludes process input descriptor(s).  */
 static SELECT_TYPE non_process_wait_mask;
@@ -3158,6 +3158,10 @@ usage: (make-network-process &rest ARGS)  */)
+#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
@@ -3174,6 +3178,7 @@ usage: (make-network-process &rest ARGS)  */)
       record_unwind_protect (unwind_request_sigio, Qnil);
       unrequest_sigio ();
   /* Do this in case we never enter the for-loop below.  */
   count1 = SPECPDL_INDEX ();
@@ -6958,20 +6963,12 @@ DEFUN ("process-filter-multibyte-p", 
-/* The first time this is called, assume keyboard input comes from DESC
-   instead of from where we used to expect it.
-   Subsequent calls mean assume input keyboard can come from DESC
-   in addition to other places.  */
-static int add_keyboard_wait_descriptor_called_flag;
+/* Add DESC to the set of keyboard input descriptors.  */
 add_keyboard_wait_descriptor (desc)
      int desc;
-  if (! add_keyboard_wait_descriptor_called_flag)
-    FD_CLR (0, &input_wait_mask);
-  add_keyboard_wait_descriptor_called_flag = 1;
   FD_SET (desc, &input_wait_mask);
   FD_SET (desc, &non_process_wait_mask);
   if (desc > max_keyboard_desc)
@@ -7043,7 +7040,12 @@ init_process ()
   process_output_skip = 0;
+  /* Don't do this, it caused infinite select loops.  The display
+     method should call add_keyboard_wait_descriptor on stdin if it
+     needs that.  */
+#if 0
   FD_SET (0, &input_wait_mask);
   Vprocess_alist = Qnil;
 #ifdef SIGCHLD

So it might be that "the display method should call
add_keyboard_wait_descriptor on stdin".  Maybe the respective code
doing that did not make it into the multi-tty branch?

David Kastrup, Kriemhildstr. 15, 44793 Bochum

reply via email to

[Prev in Thread] Current Thread [Next in Thread]