GNU bug report logs - #1578
23.0.60; [EmacsCarbon] emacsclient -c make emacs very slow (under Mac OSX)

Previous Next

Package: emacs;

Reported by: poppyer <poppyer <at> gmail.com>

Date: Wed, 17 Dec 2008 06:33:16 UTC

Severity: normal

Tags: unreproducible

Done: Andrew Hyatt <ahyatt <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: 1578 <at> debbugs.gnu.org
Cc: poppyer <poppyer <at> gmail.com>
Subject: bug#1578: emacsclient -c make emacs very slow (under Mac OSX)
Date: Thu, 22 Jan 2009 01:02:45 +0200
> First, I use emacs -nw to open a normal emacs in the terminal.  Then I
> use emacsclient -c to open a carbon frame.  Now the terminal emacs
> becomes very slow and unresponsive. (But the CPU is not running high).
> Even after the carbon frame is closed, it is still same slow. (and I
> have to close emacs and restart)

This is because the events are being passed only after a full run  
through the NS event loop.  See line 3194 in nsterm.m (the first one  
of ns_select()).  Ideally this would drop down to the regular select 
() if the NS application ("carbon" frame) is not active.  However, I  
haven't found a way to detect this without also causing the problem  
of failing to pick up the app becoming active again until after a  
long delay.  I think the select() gets called with a long timeout  
and, no matter if cocoa-experimental-ctrl-g is set or not, no  
interruption of it happens.

Since there is only one thread, an external call to, e.g. - 
applicationWillBecomeActive won't go through until after this select  
terminates.





This bug report was last modified 9 years and 62 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.