bug#1578: emacsclient -c make emacs very slow (under Mac OSX)

[poppyer]

Adrian Robert <adrian.b.robert@gmail.com> writes:

>> 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.


I notice that if I start with "emacs -nw", there is no NSApp (no icon in
the osx dock). When I use "emacsclient -c" to open a NS frame, the icon
shows up. My idea here is, if I close every NS frame, can we destroy the
NSApp and make it nil again (say by testing the frame count) ? If this
is possible, it at least make emacsclient more usable; and I don't need
to restart Emacs.

Cheers,
poppyer