unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: David Kastrup <dak@gnu.org>
To: Ted Zlatanov <tzz@lifelogs.com>
Cc: chad brown <y@mit.edu>,
	"Randal L. Schwartz" <merlyn@stonehenge.com>,
	YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>,
	emacs-devel@gnu.org
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	[thread overview]
Message-ID: <853axrbm0j.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m2odgftx5m.fsf@lifelogs.com> (Ted Zlatanov's message of "Thu\, 06 Sep 2007 14\:24\:21 -0500")

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu <dann@ics.uci.edu> 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)  */)
 
  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
@@ -3174,6 +3178,7 @@ usage: (make-network-process &rest ARGS)  */)
       record_unwind_protect (unwind_request_sigio, Qnil);
       unrequest_sigio ();
     }
+#endif
 
   /* Do this in case we never enter the for-loop below.  */
   count1 = SPECPDL_INDEX ();
@@ -6958,20 +6963,12 @@ DEFUN ("process-filter-multibyte-p", Fprocess_filter_multibyte_p,
 
 
 \f
-/* 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.  */
 
 void
 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;
 #endif
 
+  /* 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);
+#endif
 
   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	other threads:[~2007-09-06 20:02 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-06 10:02 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected Ted Zlatanov
2007-09-06 10:15 ` Ted Zlatanov
2007-09-06 10:44   ` Nick Roberts
2007-09-06 14:14 ` Dan Nicolaescu
2007-09-06 15:45   ` Ted Zlatanov
2007-09-06 16:10     ` Dan Nicolaescu
2007-09-06 16:38       ` Ted Zlatanov
2007-09-06 17:15         ` Dan Nicolaescu
2007-09-06 17:33           ` Ted Zlatanov
2007-09-06 18:43             ` Dan Nicolaescu
2007-09-06 19:24               ` Ted Zlatanov
2007-09-06 20:02                 ` David Kastrup [this message]
2007-09-06 20:16                 ` Dan Nicolaescu
2007-09-07  2:45                   ` Ted Zlatanov
2007-09-10 14:12                     ` Ted Zlatanov
2007-09-25 14:36                       ` Ted Zlatanov
2007-09-25 15:03                         ` Jason Rumney
2007-09-25 16:53                           ` Ted Zlatanov
2007-09-25 16:58                             ` Ted Zlatanov
2007-09-25 20:43                             ` Jason Rumney
2007-09-25 20:58                               ` Ted Zlatanov
2007-09-25 23:50                                 ` YAMAMOTO Mitsuharu
2007-09-26 11:48                                   ` Ted Zlatanov
2007-09-26  5:44                               ` Dan Nicolaescu
2007-09-26  7:35                                 ` Jason Rumney
2007-09-26  7:44                                   ` Jason Rumney
2007-09-26  9:19                                     ` Eli Zaretskii
2007-09-26 11:52                                       ` Ted Zlatanov
2007-09-26  5:42                             ` Dan Nicolaescu
2007-09-06 21:08                 ` Jason Rumney
2007-09-07  6:32     ` Richard Stallman

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=853axrbm0j.fsf@lola.goethe.zz \
    --to=dak@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=merlyn@stonehenge.com \
    --cc=mituharu@math.s.chiba-u.ac.jp \
    --cc=tzz@lifelogs.com \
    --cc=y@mit.edu \
    /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).