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

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

[Adrian Robert]

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

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

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

[Adrian Robert]

On Feb 6, 2009, at 8:26 PM, poppyer wrote:

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

This a good idea and would probably meet better with user  
expectations when the only frame is closed (get rid of the icon in  
the dock), also applicable when started with --daemon.

I don't have time to work on it right now, so if someone else wants  
to take a crack.. it shouldn't be that hard (though there could be  
unexpected gotchas I guess)...

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

[Stefan Monnier]

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

> This a good idea and would probably meet better with user expectations when
> the only frame is closed (get rid of the icon in  the dock), also applicable
> when started with --daemon.

> I don't have time to work on it right now, so if someone else wants to take
> a crack.. it shouldn't be that hard (though there could be  unexpected
> gotchas I guess)...

Odd: I'm not a regular Mac OS X user, but from the little bit of
exposure I've had to this system, I would have expected the exact
opposite: I'd have expected "emacs --daemon" to bring up the Emacs icon
in the dock even before the first frame is opened, and would stay there
until the daemon exits.


        Stefan

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

[Hagmonk]

I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.

nsterm.m has been reworked somewhat over the past 6 years, including ns_read_socket which I believe is the function in question based on the conditional it used to have to check whether it was “inNsSelect”.

I’d suggest returning this to the reporter for verification.

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

[Andrew Hyatt]

Seeing how this was marked unreproducible for a few weeks now, I'm going
to close this out.  Someone can re-open if it still can reproduce on Emacs
25.

Hagmonk <hagmonk@icloud.com> writes:

> I’m unable to reproduce this bug using Emacs 25.0.92.2 on OS X 10.11.3.
>
> nsterm.m has been reworked somewhat over the past 6 years, including
> ns_read_socket which I believe is the function in question based on the
> conditional it used to have to check whether it was “inNsSelect”.
>
> I’d suggest returning this to the reporter for verification.