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

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

[poppyer]

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)




In GNU Emacs 23.0.60.1 (i386-apple-darwin9.5.0, NS apple-appkit-949.35)
 of 2008-12-11 on neutron.local
Windowing system distributor `Apple', version 97.112.112.108.101.45.97.112.112.107.105.116.45.57.52.57.46.51.53
configured using `configure  '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: zh_CN.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix
  default-enable-multibyte-characters: t

Major mode: Summary

Minor modes in effect:
  gnus-agent-mode: t
  erc-log-mode: t
  erc-list-mode: t
  erc-menu-mode: t
  erc-autojoin-mode: t
  erc-ring-mode: t
  erc-networks-mode: t
  erc-pcomplete-mode: t
  erc-track-mode: t
  erc-track-minor-mode: t
  erc-match-mode: t
  erc-button-mode: t
  erc-fill-mode: t
  erc-stamp-mode: t
  erc-netsplit-mode: t
  erc-irccontrols-mode: t
  erc-noncommands-mode: t
  erc-move-to-prompt-mode: t
  erc-readonly-mode: t
  iswitchb-mode: t
  recentf-mode: t
  which-function-mode: t
  show-paren-mode: t
  mouse-sel-mode: t
  global-hl-line-mode: t
  pinbar-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
RET ESC x n e w s C-p C-p RET q n n n n n p p RET SPC 
n SPC C-n SPC n q p p RET C-n C-n C-n C-n C-n C-p C-p 
C-p SPC SPC C-n SPC SPC C-n SPC c y p n n n n n n n 
n n n n n p p p p p p p p p n n n n n p p p p p n n 
n n n n p p p n n n p RET SPC q RET C-n C-n C-n C-n 
C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n 
C-n C-n C-n C-p c y p p p p n RET SPC n n c y ESC [ 
B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC [ B ESC 
[ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A ESC [ A 
p n RET SPC q p RET SPC q p RET SPC SPC C-n SPC SPC 
q C-c C-@ C-c C-@ C-c C-@ ESC 1 C-p C-p C-p C-p C-p 
C-p ESC g n RET SPC n C-x 1 ESC x b DEL s u b TAB ESC 
DEL ESC DEL e m TAB a TAB s u m i TAB TAB ESC DEL r 
e TAB ESC DEL ESC DEL r e p o TAB r TAB e DEL TAB 
RET

Recent messages:
Generating summary...done
Reading active file from gmail via nnimap...
nnimap: Checking mailboxes...done
Reading active file from freenews.netfront.net via nntp...
Checking new news...done
Retrieving newsgroup: nntp+freenews.netfront.net:cn.bbs.comp.emacs...
Fetching headers for nntp+freenews.netfront.net:cn.bbs.comp.emacs...done
Scoring...done
Generating summary...done
Making completion list... [2 times]

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.