emacs-devel
[Top][All Lists]
Advanced

[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: Ted Zlatanov
Subject: Re: 23.0.50; MacOS X 10.4: very slow visuals, multi-tty patch suspected
Date: Tue, 25 Sep 2007 09:36:12 -0500
User-agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1.50 (darwin)

On Mon, 10 Sep 2007 09:12:38 -0500 Ted Zlatanov <address@hidden> wrote: 

TZ> On Thu, 06 Sep 2007 21:45:34 -0500 Ted Zlatanov <address@hidden> wrote: 
TZ> On Thu, 06 Sep 2007 13:16:32 -0700 Dan Nicolaescu <address@hidden> wrote: 
DN> 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?
>>>> 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.

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

Hi,

it's been two weeks and no one has suggested a fix for this issue.
Despite some discussion on external Emacs Cocoa/Carbon ports, there was
no consensus (as far as I am aware) on what the Emacs project itself
will do about the currently broken Cocoa build.

I would suggest at least disabling the Emacs Cocoa build for MacOS X, if
the Emacs project can't run reliably there in a graphical mode; the text
mode build can continue to work normally.  The problem should also be
documented in case someone with interest can fix it.

Ted





reply via email to

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