From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel 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 Message-ID: <853axrbm0j.fsf@lola.goethe.zz> References: <200709061414.l86EEwQE013656@oogie-boogie.ics.uci.edu> <200709061610.l86GAA2D017210@oogie-boogie.ics.uci.edu> <200709061715.l86HFHXx020325@oogie-boogie.ics.uci.edu> <200709061843.l86IhFrJ023998@oogie-boogie.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1189108964 16437 80.91.229.12 (6 Sep 2007 20:02:44 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 6 Sep 2007 20:02:44 +0000 (UTC) Cc: chad brown , "Randal L. Schwartz" , YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: Ted Zlatanov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Sep 06 22:02:43 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1ITNYk-0003Go-Ds for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2007 22:02:38 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITNYi-0004Ct-GB for ged-emacs-devel@m.gmane.org; Thu, 06 Sep 2007 16:02:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ITNYe-00048w-UQ for emacs-devel@gnu.org; Thu, 06 Sep 2007 16:02:32 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ITNYd-000486-BO for emacs-devel@gnu.org; Thu, 06 Sep 2007 16:02:32 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ITNYd-000483-8t for emacs-devel@gnu.org; Thu, 06 Sep 2007 16:02:31 -0400 Original-Received: from mail-in-07.arcor-online.net ([151.189.21.47]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1ITNYc-00015m-Hc for emacs-devel@gnu.org; Thu, 06 Sep 2007 16:02:30 -0400 Original-Received: from mail-in-06-z2.arcor-online.net (mail-in-06-z2.arcor-online.net [151.189.8.18]) by mail-in-07.arcor-online.net (Postfix) with ESMTP id F37E324B0BC; Thu, 6 Sep 2007 22:02:24 +0200 (CEST) Original-Received: from mail-in-06.arcor-online.net (mail-in-06.arcor-online.net [151.189.21.46]) by mail-in-06-z2.arcor-online.net (Postfix) with ESMTP id E4E9BABAB4; Thu, 6 Sep 2007 22:02:24 +0200 (CEST) Original-Received: from lola.goethe.zz (dslb-084-061-057-134.pools.arcor-ip.net [84.61.57.134]) by mail-in-06.arcor-online.net (Postfix) with ESMTP id B659D376443; Thu, 6 Sep 2007 22:02:24 +0200 (CEST) Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id D87421CAD71B; Thu, 6 Sep 2007 22:02:21 +0200 (CEST) In-Reply-To: (Ted Zlatanov's message of "Thu\, 06 Sep 2007 14\:24\:21 -0500") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (gnu/linux) X-Virus-Scanned: ClamAV 0.91.2/4173/Thu Sep 6 20:35:28 2007 on mail-in-06.arcor-online.net X-Virus-Status: Clean X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:78015 Archived-At: Ted Zlatanov writes: > On Thu, 06 Sep 2007 11:43:15 -0700 Dan Nicolaescu 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, -/* 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