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

[Ted Zlatanov <tzz@lifelogs.com>]

On Thu, 06 Sep 2007 21:45:34 -0500 Ted Zlatanov <tzz@lifelogs.com> wrote: 

TZ> On Thu, 06 Sep 2007 13:16:32 -0700 Dan Nicolaescu <dann@ics.uci.edu> wrote: 
DN> 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?
>>> Should we increase the frequency of the SIGALRM polling instead?

DN> Can you try to do what the comment in the code says: add a call to
DN> add_keyboard_wait_descriptor? Probably mac_term_init is the place to
DN> do that. 

TZ> I added:

TZ>   int desc = 0;
TZ>   printf("Setting up FD %d\n", desc);
TZ>   /* replacing the call FD_SET (0, &input_wait_mask) from process.c */
TZ>   add_keyboard_wait_descriptor(desc);

TZ> before, during, and after the BLOCK_INPUT/UNBLOCK_INPUT portion, and it
TZ> didn't help.  Input was still very slow.  I put in the printf to be sure
TZ> the function was running.  If I'm missing something, let me know please.

Anyone with new suggestions?  Am I doing add_keyboard_wait_descriptor()
in the right place?  Should I do multiple calls?  Can we look at
increasing the SIGALRM frequency as a workaround?

Thanks
Ted