bug#24091: 24.5; High CPU usage at startup while hidden

bug#24091: 24.5; High CPU usage at startup while hidden

[aiken]

I am using the i3 window manager. When I launch emacs (via dmenu) while
in a workspace, call it workspace A, and switch to workspace B before
the emacs window appears, then eventually it loads up in A, but during
this time, emacs' CPU usage is very high. It remains high until I switch
back to A, at which point its CPU usage becomes normal. I've also tried
launching emacs with my init.el disabled (commented out) and get the
same result.



In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
 of 2016-04-17 on lgw01-04, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11803000
System Description:	Ubuntu 16.04.1 LTS

Configured using:
 `configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
 --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
 --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
 -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  mml-mode: t
  global-linum-mode: t
  linum-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
Sending...
message-send: No methods specified to send by
Mark set
Sending...
message-send: No methods specified to send by
Mark set
Sending...
message-send: No methods specified to send by
Mark set
Mark deactivated

Load-path shadows:
/home/aiken/.emacs.d/elpa/helm-20160715.2117/helm-multi-match hides
/home/aiken/.emacs.d/elpa/helm-core-20160716.3/helm-multi-match
/usr/share/emacs/24.5/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup

Features:
(pp shadow sort gnus-util mail-extr emacsbug message format-spec rfc822
mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode ido tango-theme linum edmacro
kmacro cl-loaddefs cl-lib paren cus-start cus-load easymenu package
epg-config time-date tooltip electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 148256 14891)
 (symbols 48 23209 0)
 (miscs 40 214 233)
 (strings 32 30777 8686)
 (string-bytes 1 780663)
 (vectors 16 14596)
 (vector-slots 8 441793 11029)
 (floats 8 87 340)
 (intervals 56 789 779)
 (buffers 960 14)
 (heap 1024 45744 1545))

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Wed, Jul 27, 2016 at 7:11 PM, aiken <acairncross@gmail.com> wrote:
> I am using the i3 window manager. When I launch emacs (via dmenu) while
> in a workspace, call it workspace A, and switch to workspace B before
> the emacs window appears, then eventually it loads up in A,

For me, the emacs window appears in workspace B. Is there some setting
you need to make it appear in the starting workspace?

bug#24091: 24.5; High CPU usage at startup while hidden

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 4957 bytes --]

Thanks for the bug report. Just to confirm that this isn't a configuration issue, can you try starting Emacs as `emacs -Q` and reproducing the issue?

If the problem persists in `emacs -Q`, maybe a trace generated by running M-x profiler-start before changing workspaces and M-x profiler-report after returning to the first workspace would help? You can save the profile with profiler-report-save-profile.

Cheers,
Clément.

On 2016-07-27 19:11, aiken wrote:
> I am using the i3 window manager. When I launch emacs (via dmenu) while
> in a workspace, call it workspace A, and switch to workspace B before
> the emacs window appears, then eventually it loads up in A, but during
> this time, emacs' CPU usage is very high. It remains high until I switch
> back to A, at which point its CPU usage becomes normal. I've also tried
> launching emacs with my init.el disabled (commented out) and get the
> same result.
> 
> 
> 
> In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
>  of 2016-04-17 on lgw01-04, modified by Debian
> Windowing system distributor `The X.Org Foundation', version 11.0.11803000
> System Description:	Ubuntu 16.04.1 LTS
> 
> Configured using:
>  `configure --build x86_64-linux-gnu --prefix=/usr
>  --sharedstatedir=/var/lib --libexecdir=/usr/lib
>  --localstatedir=/var/lib --infodir=/usr/share/info
>  --mandir=/usr/share/man --with-pop=yes
>  --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
>  --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
>  --libexecdir=/usr/lib --localstatedir=/var/lib
>  --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
>  --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
>  --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
>  'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
>  -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
>  -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
> 
> Important settings:
>   value of $LANG: en_GB.UTF-8
>   locale-coding-system: utf-8-unix
> 
> Major mode: Message
> 
> Minor modes in effect:
>   mml-mode: t
>   global-linum-mode: t
>   linum-mode: t
>   show-paren-mode: t
>   electric-indent-mode: t
>   mouse-wheel-mode: t
>   file-name-shadow-mode: t
>   global-font-lock-mode: t
>   font-lock-mode: t
>   blink-cursor-mode: t
>   auto-composition-mode: t
>   auto-encryption-mode: t
>   auto-compression-mode: t
>   line-number-mode: t
>   auto-fill-function: message-do-auto-fill
>   transient-mark-mode: t
>   abbrev-mode: t
> 
> Recent messages:
> Sending...
> message-send: No methods specified to send by
> Mark set
> Sending...
> message-send: No methods specified to send by
> Mark set
> Sending...
> message-send: No methods specified to send by
> Mark set
> Mark deactivated
> 
> Load-path shadows:
> /home/aiken/.emacs.d/elpa/helm-20160715.2117/helm-multi-match hides
> /home/aiken/.emacs.d/elpa/helm-core-20160716.3/helm-multi-match
> /usr/share/emacs/24.5/site-lisp/debian-startup hides
> /usr/share/emacs/site-lisp/debian-startup
> 
> Features:
> (pp shadow sort gnus-util mail-extr emacsbug message format-spec rfc822
> mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
> gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
> help-fns mail-prsvr mail-utils help-mode ido tango-theme linum edmacro
> kmacro cl-loaddefs cl-lib paren cus-start cus-load easymenu package
> epg-config time-date tooltip electric uniquify ediff-hook vc-hooks
> lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
> fringe tabulated-list newcomment lisp-mode prog-mode register page
> menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
> syntax facemenu font-core frame cham georgian utf-8-lang misc-lang
> vietnamese tibetan thai tai-viet lao korean japanese hebrew greek
> romanian slovak czech european ethiopic indian cyrillic chinese
> case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice
> loaddefs button faces cus-face macroexp files text-properties overlay
> sha1 md5 base64 format env code-pages mule custom widget
> hashtable-print-readable backquote make-network-process dbusbind
> gfilenotify dynamic-setting system-font-setting font-render-setting
> move-toolbar gtk x-toolkit x multi-tty emacs)
> 
> Memory information:
> ((conses 16 148256 14891)
>  (symbols 48 23209 0)
>  (miscs 40 214 233)
>  (strings 32 30777 8686)
>  (string-bytes 1 780663)
>  (vectors 16 14596)
>  (vector-slots 8 441793 11029)
>  (floats 8 87 340)
>  (intervals 56 789 779)
>  (buffers 960 14)
>  (heap 1024 45744 1545))
> 
> 
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24091: 24.5; High CPU usage at startup while hidden

[aiken]

Noam: I think my settings are fairly standard, but another way to
reproduce the effect of Emacs launching in a workspace that you're not
currently in (which seems to be the main issue) is to add something like
"assign [class="Emacs24"] 9" to your i3 config. (I've tried this and it
does reproduce the high CPU usage.)

Clément: I still get the problem with `emacs -Q`. Some clarification
about the problem: the high CPU usage starts while Emacs is launching on
some other workspace, and stops as soon as I go to that workspace. I
notice that, when I go to the Emacs workspace and see the Emacs window,
Emacs hasn't actually loaded up fully (e.g. it hasn't loaded my
init.el), and it only finishes a lot of its startup once I'm on that
workspace. Anyway, since the problem stops as soon as I look at Emacs,
the only way I know of running profiler-report for this purpose is by
putting it in a command line option: `emacs -Q --eval "(profiler-start
'cpu)"`. So I've done this (see below for the report), but I'm pretty
sure the profiler-start is only getting evaluated after I've moved to
the Emacs workspace, i.e. after the problem has stopped.


[profiler-profile "24.3" cpu #s(hash-table size 65 test equal
rehash-size 1.5 rehash-threshold 0.8 data ([nil nil nil nil nil nil nil
nil nil nil nil nil nil nil nil nil] 61 [and or and redisplay_internal\
\(C\ function\) nil nil nil nil nil nil nil nil nil nil nil nil] 4
[completing-read-default completing-read read-extended-command byte-code
call-interactively command-execute nil nil nil nil nil nil nil nil nil
nil] 24 [and or and redisplay_internal\ \(C\ function\)
read-from-minibuffer completing-read-default completing-read
read-extended-command byte-code call-interactively command-execute nil
nil nil nil nil] 3 [read-from-minibuffer completing-read-default
completing-read read-extended-command byte-code call-interactively
command-execute nil nil nil nil nil nil nil nil nil] 37
[completion-basic-try-completion "#<compiled 0x4c2287>" "#<compiled
0x4c267f>" funcall completion--some completion--nth-completion
completion-try-completion completion--do-completion
completion--in-region-1 "#<compiled 0x247e21>" apply "#<compiled
0x4c1a7f>" completion--in-region completion-in-region
minibuffer-complete call-interactively] 5
[completion-pcm--all-completions "#<compiled 0x4c3299>" funcall
completion-pcm--find-all-completions completion-pcm-try-completion
"#<compiled 0x4c2287>" "#<compiled 0x4c2a8f>" funcall completion--some
completion--nth-completion completion-try-completion
completion--do-completion completion--in-region-1 "#<compiled 0x247e21>"
apply "#<compiled 0x4c1a7f>"] 4 [completion-emacs22-try-completion
"#<compiled 0x4c2287>" "#<compiled 0x4c3e97>" funcall completion--some
completion--nth-completion completion-try-completion
completion--do-completion completion--in-region-1 "#<compiled 0x247e21>"
apply "#<compiled 0x4c1a7f>" completion--in-region completion-in-region
minibuffer-complete call-interactively] 4 [sit-for minibuffer-message
completion--message completion--do-completion completion--in-region-1
"#<compiled 0x247e21>" apply "#<compiled 0x4c1a7f>"
completion--in-region completion-in-region minibuffer-complete
call-interactively command-execute read-from-minibuffer
completing-read-default completing-read] 2 [delete-backward-char
call-interactively command-execute read-from-minibuffer
completing-read-default completing-read read-extended-command byte-code
call-interactively command-execute nil nil nil nil nil nil] 1
[profiler-cpu-profile profiler-report-cpu profiler-report
call-interactively command-execute execute-extended-command
call-interactively command-execute nil nil nil nil nil nil nil nil] 14
[Automatic\ GC] 2)) (22426 16956 108810 96000) nil]

bug#24091: 24.5; High CPU usage at startup while hidden

[Clément Pit--Claudel]

[-- Attachment #1.1: Type: text/plain, Size: 1546 bytes --]

On 2016-07-28 13:43, aiken wrote:
> Clément: I still get the problem with `emacs -Q`. Some clarification
> about the problem: the high CPU usage starts while Emacs is launching on
> some other workspace, and stops as soon as I go to that workspace. I
> notice that, when I go to the Emacs workspace and see the Emacs window,
> Emacs hasn't actually loaded up fully (e.g. it hasn't loaded my
> init.el), and it only finishes a lot of its startup once I'm on that
> workspace. Anyway, since the problem stops as soon as I look at Emacs,
> the only way I know of running profiler-report for this purpose is by
> putting it in a command line option: `emacs -Q --eval "(profiler-start
> 'cpu)"`. So I've done this (see below for the report), but I'm pretty
> sure the profiler-start is only getting evaluated after I've moved to
> the Emacs workspace, i.e. after the problem has stopped.

Interesting, thanks. Indeed, the profile doesn't show much of interest, and does not seem to have run very long.
I'm not very knowledgeable at all about these parts of Emacs, so I hope that an expert can offer more suggestions. I can offer a few suggestions, however:

* You could try enabling C-level profiling, if you're fine with recompiling Emacs; this should capture most of Emacs' activity.
* You could try getting a backtrace while Emacs is busy starting, from the other desktop; either using gdb if it's busy in C-code, or with pkill -SIGUSR2 if it's busy with Lisp code.

Btw, was this profile obtained with Emacs 24.5, or 24.3?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

bug#24091: 24.5; High CPU usage at startup while hidden

[aiken]

> Btw, was this profile obtained with Emacs 24.5, or 24.3?

If you're asking because of the "24.3" in the profiler report, I have no
idea why it says that, since the Emacs version is definitely 24.5.

bug#24091: 24.5; High CPU usage at startup while hidden

[npostavs]

tags 24091 confirmed
found 24091 25.1-rc1
quit

aiken <acairncross@gmail.com> writes:

> Noam: I think my settings are fairly standard, but another way to
> reproduce the effect of Emacs launching in a workspace that you're not
> currently in (which seems to be the main issue) is to add something like
> "assign [class="Emacs24"] 9" to your i3 config. (I've tried this and it
> does reproduce the high CPU usage.)

Thanks, with this I'm able to reproduce also with the latest emacs-25.
I sent SIGSTOP to get a backtrace and found it was in
x_make_frame_visible (src/xterm.c).

Stepping through it with gdb, I saw it's getting stuck in this loop:

    /* Process X events until a MapNotify event has been seen.  */
    while (!FRAME_VISIBLE_P (f))
      {
        /* Force processing of queued events.  */
        x_sync (f);

        /* If on another desktop, the deiconify/map may be ignored and the
           frame never becomes visible.  XMonad does this.
           Prevent an endless loop.  */
        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

       /* This hack is still in use at least for Cygwin.  See
           http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html.

           Machines that do polling rather than SIGIO have been
           observed to go into a busy-wait here.  So we'll fake an
           alarm signal to let the handler know that there's something
           to be read.  We used to raise a real alarm, but it seems
           that the handler isn't always enabled here.  This is
           probably a bug.  */
        if (input_polling_used ())
          {
            /* It could be confusing if a real alarm arrives while
               processing the fake one.  Turn it off and let the
               handler reset it.  */
            int old_poll_suppress_count = poll_suppress_count;
            poll_suppress_count = 1;
            poll_for_input_1 ();
            poll_suppress_count = old_poll_suppress_count;
          }

        if (XPending (FRAME_X_DISPLAY (f)))
          {
            XEvent xev;
            XNextEvent (FRAME_X_DISPLAY (f), &xev);
            x_dispatch_event (&xev, FRAME_X_DISPLAY (f));
          }
      }


I guess we would like Emacs to hit this case:

        /* If on another desktop, the deiconify/map may be ignored and the
           frame never becomes visible.  XMonad does this.
           Prevent an endless loop.  */
        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

But it seems that FRAME_ICONIFIED_P is returning false, because I see
that tries is never incremented.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Date: Thu, 28 Jul 2016 21:45:55 -0400
> Cc: clement.pit@gmail.com, 24091@debbugs.gnu.org
> 
> I guess we would like Emacs to hit this case:
> 
>         /* If on another desktop, the deiconify/map may be ignored and the
>            frame never becomes visible.  XMonad does this.
>            Prevent an endless loop.  */
>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>           break;
> 
> But it seems that FRAME_ICONIFIED_P is returning false, because I see
> that tries is never incremented.

The question is: what happens if you bypass that loop and let Emacs
proceed with startup?  Does it successfully finish the startup, or
does it error out or crash later on?

If the former, we need to find a way to detect this special situation,
and maybe bypass the loop altogether.  If the latter, we will either
need to find a way to avoid that subsequent crash, or continue
waiting, perhaps with some 'usleep' call in the loop, to avoid hogging
the CPU.

Thanks.

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Fri, Jul 29, 2016 at 1:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: npostavs@users.sourceforge.net
>> Date: Thu, 28 Jul 2016 21:45:55 -0400
>> Cc: clement.pit@gmail.com, 24091@debbugs.gnu.org
>>
>> I guess we would like Emacs to hit this case:
>>
>>         /* If on another desktop, the deiconify/map may be ignored and the
>>            frame never becomes visible.  XMonad does this.
>>            Prevent an endless loop.  */
>>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>>           break;
>>
>> But it seems that FRAME_ICONIFIED_P is returning false, because I see
>> that tries is never incremented.
>
> The question is: what happens if you bypass that loop and let Emacs
> proceed with startup?  Does it successfully finish the startup, or
> does it error out or crash later on?

Works fine, no crashes.

>
> If the former, we need to find a way to detect this special situation,
> and maybe bypass the loop altogether.

Hmm, not really sure where to start.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 30 Jul 2016 09:54:55 -0400
> Cc: acairncross@gmail.com, clement.pit@gmail.com, 24091@debbugs.gnu.org
> 
> >> But it seems that FRAME_ICONIFIED_P is returning false, because I see
> >> that tries is never incremented.
> >
> > The question is: what happens if you bypass that loop and let Emacs
> > proceed with startup?  Does it successfully finish the startup, or
> > does it error out or crash later on?
> 
> Works fine, no crashes.
> 
> >
> > If the former, we need to find a way to detect this special situation,
> > and maybe bypass the loop altogether.
> 
> Hmm, not really sure where to start.

I'd start by finding out why FRAME_ICONIFIED_P returns false.

bug#24091: 24.5; High CPU usage at startup while hidden

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 30 Jul 2016 09:54:55 -0400
>> Cc: acairncross@gmail.com, clement.pit@gmail.com, 24091@debbugs.gnu.org
>> 
>> >> But it seems that FRAME_ICONIFIED_P is returning false, because I see
>> >> that tries is never incremented.
>> >
>> > The question is: what happens if you bypass that loop and let Emacs
>> > proceed with startup?  Does it successfully finish the startup, or
>> > does it error out or crash later on?
>> 
>> Works fine, no crashes.
>> 
>> >
>> > If the former, we need to find a way to detect this special situation,
>> > and maybe bypass the loop altogether.
>> 
>> Hmm, not really sure where to start.
>
> I'd start by finding out why FRAME_ICONIFIED_P returns false.

Well, it seems that's because Emacs never receives an UnmapNotify event.
But that doesn't feel like I'm getting any closer to a solution...

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: 24091@debbugs.gnu.org,  acairncross@gmail.com,  clement.pit@gmail.com
> Date: Sat, 13 Aug 2016 19:57:54 -0400
> 
> >> > The question is: what happens if you bypass that loop and let Emacs
> >> > proceed with startup?  Does it successfully finish the startup, or
> >> > does it error out or crash later on?
> >> 
> >> Works fine, no crashes.
> >> 
> >> >
> >> > If the former, we need to find a way to detect this special situation,
> >> > and maybe bypass the loop altogether.
> >> 
> >> Hmm, not really sure where to start.
> >
> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
> 
> Well, it seems that's because Emacs never receives an UnmapNotify event.
> But that doesn't feel like I'm getting any closer to a solution...

What events does Emacs get in that case?

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Mon, Aug 15, 2016 at 10:38 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: npostavs@users.sourceforge.net
>> Cc: 24091@debbugs.gnu.org,  acairncross@gmail.com,  clement.pit@gmail.com
>> Date: Sat, 13 Aug 2016 19:57:54 -0400
>>
>> >> > The question is: what happens if you bypass that loop and let Emacs
>> >> > proceed with startup?  Does it successfully finish the startup, or
>> >> > does it error out or crash later on?
>> >>
>> >> Works fine, no crashes.
>> >>
>> >> >
>> >> > If the former, we need to find a way to detect this special situation,
>> >> > and maybe bypass the loop altogether.
>> >>
>> >> Hmm, not really sure where to start.
>> >
>> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
>>
>> Well, it seems that's because Emacs never receives an UnmapNotify event.
>> But that doesn't feel like I'm getting any closer to a solution...
>
> What events does Emacs get in that case?

Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
ReparentNotify events.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 3 Sep 2016 13:29:39 -0400
> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>, 
> 	Clément Pit--Claudel <clement.pit@gmail.com>
> 
> >> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
> >>
> >> Well, it seems that's because Emacs never receives an UnmapNotify event.
> >> But that doesn't feel like I'm getting any closer to a solution...
> >
> > What events does Emacs get in that case?
> 
> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
> ReparentNotify events.

Does it work to turn this:

        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
          break;

into this:

        if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
          break;

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sat, Sep 3, 2016 at 1:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 13:29:39 -0400
>> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>,
>>       Clément Pit--Claudel <clement.pit@gmail.com>
>>
>> >> > I'd start by finding out why FRAME_ICONIFIED_P returns false.
>> >>
>> >> Well, it seems that's because Emacs never receives an UnmapNotify event.
>> >> But that doesn't feel like I'm getting any closer to a solution...
>> >
>> > What events does Emacs get in that case?
>>
>> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
>> ReparentNotify events.
>
> Does it work to turn this:
>
>         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>           break;
>
> into this:
>
>         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>           break;

No, which sort of makes sense since the frame isn't actually visible.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 3 Sep 2016 13:53:40 -0400
> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>, 
> 	Clément Pit--Claudel <clement.pit@gmail.com>
> 
> >> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
> >> ReparentNotify events.
> >
> > Does it work to turn this:
> >
> >         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
> >           break;
> >
> > into this:
> >
> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
> >           break;
> 
> No, which sort of makes sense since the frame isn't actually visible.

But you said the MapNotify event was received?  Doesn't that cause the
frame to become marked as visible?

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sat, Sep 3, 2016 at 2:35 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 13:53:40 -0400
>> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>,
>>       Clément Pit--Claudel <clement.pit@gmail.com>
>>
>> >> Emacs is getting PropertyNotify, ConfigureNotify, MapNotify, and
>> >> ReparentNotify events.
>> >
>> > Does it work to turn this:
>> >
>> >         if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
>> >           break;
>> >
>> > into this:
>> >
>> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>> >           break;
>>
>> No, which sort of makes sense since the frame isn't actually visible.
>
> But you said the MapNotify event was received?  Doesn't that cause the
> frame to become marked as visible?

Only if x_top_window_to_frame returns non-nil, which it does not.

    case MapNotify:
      /* We use x_top_window_to_frame because map events can
         come for sub-windows and they don't mean that the
         frame is visible.  */
      f = x_top_window_to_frame (dpyinfo, event->xmap.window);
      if (f)
        {
...
          SET_FRAME_VISIBLE (f, 1);
...
        }
      goto OTHER;

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sat, 3 Sep 2016 14:40:23 -0400
> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>, 
> 	Clément Pit--Claudel <clement.pit@gmail.com>
> 
> >> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
> >> >           break;
> >>
> >> No, which sort of makes sense since the frame isn't actually visible.
> >
> > But you said the MapNotify event was received?  Doesn't that cause the
> > frame to become marked as visible?
> 
> Only if x_top_window_to_frame returns non-nil, which it does not.

Why doesn't it, in this case, and how are things different with a
"normal" startup, which doesn't infloop?

Btw, I'm only asking these questions on the assumption that we have no
working idea for how to solve this.  If that assumption is false, feel
free to ignore me.

Thanks.

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sat, Sep 3, 2016 at 2:51 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sat, 3 Sep 2016 14:40:23 -0400
>> Cc: 24091@debbugs.gnu.org, Aiken <acairncross@gmail.com>,
>>       Clément Pit--Claudel <clement.pit@gmail.com>
>>
>> >> >         if ((FRAME_ICONIFIED_P (f) || FRAME_VISIBLE_P (f)) &&  ++tries > 100)
>> >> >           break;
>> >>
>> >> No, which sort of makes sense since the frame isn't actually visible.
>> >
>> > But you said the MapNotify event was received?  Doesn't that cause the
>> > frame to become marked as visible?
>>
>> Only if x_top_window_to_frame returns non-nil, which it does not.
>
> Why doesn't it, in this case, and how are things different with a
> "normal" startup, which doesn't infloop?

Hmm, it's hard to tell. In the case where Emacs is opening in the
current workspace, event->xmap.window corresponds XtWindow
(f->output_data.x->widget) and in the problematic case of opening
Emacs in another workspace, it doesn't. The contents of event are
created in the guts of Xlib I guess, which makes it somewhat
mysterious.

>
> Btw, I'm only asking these questions on the assumption that we have no
> working idea for how to solve this.  If that assumption is false, feel
> free to ignore me.

No firm ideas, but as I've been stepping around this code, I'm more
and more wondering why we have this loop at all. The comment above
x_make_frame_visible says

/* This tries to wait until the frame is really visible.
   However, if the window manager asks the user where to position
   the frame, this will return before the user finishes doing that.
   The frame will not actually be visible at that time,
   but it will become visible later when the window manager
   finishes with it.  */

So I guess the loop is the part that "tries to wait". But if that
doesn't even work some of the time, why is it really necessary at all?
The code running after this function returns can't rely on this
working, so it would have to handle the not-yet-visible case anyway...

bug#24091: 24.5; High CPU usage at startup while hidden

[martin rudalics]

 > Only if x_top_window_to_frame returns non-nil, which it does not.
 >
 >      case MapNotify:
 >        /* We use x_top_window_to_frame because map events can
 >           come for sub-windows and they don't mean that the
 >           frame is visible.  */
 >        f = x_top_window_to_frame (dpyinfo, event->xmap.window);

Where in x_window_to_frame does it fail?

martin

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sun, Sep 4, 2016 at 3:33 AM, martin rudalics <rudalics@gmx.at> wrote:
>> Only if x_top_window_to_frame returns non-nil, which it does not.
>>
>>      case MapNotify:
>>        /* We use x_top_window_to_frame because map events can
>>           come for sub-windows and they don't mean that the
>>           frame is visible.  */
>>        f = x_top_window_to_frame (dpyinfo, event->xmap.window);
>
> Where in x_window_to_frame does it fail?

In case of opening Emacs on a different workspace, there are 2
MapNotify events before the infloop of x_make_frame_visible.

x_window_to_frame has a FOR_EACH_FRAME loop.

The 1st time, there is only one iteration of the frame loop and
FRAME_X_P (f) is false.
The 2nd time, there are two iterations of the frame loop. In the first
iteration, (wdesc == XtWindow (x->widget)) is false. In the second
iteration, FRAME_X_P (f) is false, like in the 1st MapNotify event.

bug#24091: 24.5; High CPU usage at startup while hidden

[martin rudalics]

 > The 2nd time, there are two iterations of the frame loop. In the first
 > iteration, (wdesc == XtWindow (x->widget)) is false.

I suppose this happens for the frame x_make_frame_visible is waiting for
to become visible.  Correct?

martin

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sun, Sep 4, 2016 at 9:15 AM, martin rudalics <rudalics@gmx.at> wrote:
>> The 2nd time, there are two iterations of the frame loop. In the first
>> iteration, (wdesc == XtWindow (x->widget)) is false.
>
> I suppose this happens for the frame x_make_frame_visible is waiting for
> to become visible.  Correct?

Having trouble parsing your sentence. This happens before
x_make_frame_visible gets called, and before the actual frame is
visible. Is that what you're asking?

During the infloop[1] of x_make_frame_visible, I can see an indication
for a new window coming up in the target workspace, but the frame is
still not visible because I haven't switched to the workspace yet. The
infloop gets one ConfigureNotify event, and then nothing else.


[1]: This one:
    /* Process X events until a MapNotify event has been seen.  */
    while (!FRAME_VISIBLE_P (f))

bug#24091: 24.5; High CPU usage at startup while hidden

[martin rudalics]

 > Having trouble parsing your sentence. This happens before
 > x_make_frame_visible gets called, and before the actual frame is
 > visible. Is that what you're asking?

Sorry for being unclear: In x_make_frame_visible we have this loop:

     while (!FRAME_VISIBLE_P (f))

What I wanted to know is whether the frame f here is the _same_ frame
you see in x_top_window_to_frame where IIUC

	  if (wdesc == XtWindow (x->widget))
	    return f;

fails.  I see no other place where "(wdesc == XtWindow (x->widget)) is
false" would apply.  Or am I missing something?

martin

bug#24091: 24.5; High CPU usage at startup while hidden

[Noam Postavsky]

On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics@gmx.at> wrote:
> In x_make_frame_visible we have this loop:
>
>     while (!FRAME_VISIBLE_P (f))
>
> What I wanted to know is whether the frame f here is the _same_ frame
> you see in x_top_window_to_frame where IIUC
>
>           if (wdesc == XtWindow (x->widget))
>             return f;

Oh, I see. Yes, it is the same frame.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 4 Sep 2016 12:21:20 -0400
> Cc: Aiken <acairncross@gmail.com>,
> 	Clément Pit--Claudel <clement.pit@gmail.com>,
> 	24091@debbugs.gnu.org
> 
> On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics@gmx.at> wrote:
> > In x_make_frame_visible we have this loop:
> >
> >     while (!FRAME_VISIBLE_P (f))
> >
> > What I wanted to know is whether the frame f here is the _same_ frame
> > you see in x_top_window_to_frame where IIUC
> >
> >           if (wdesc == XtWindow (x->widget))
> >             return f;
> 
> Oh, I see. Yes, it is the same frame.

Maybe we should stop waiting after some time has passed, like 0.5
sec.  Does that work in this case?  Does the frame always appears
within half a second when workspaces are not involved?

Thanks.

bug#24091: 24.5; High CPU usage at startup while hidden

[Dominik Schrempf]

Hello,

I do not want to bring up old threads, but I am having the exact same
problem with Emacs+XMonad for years now.  Did you come to a conclusion
or find a fix back in September?

Thanks,
Dominik

On Tue, Sep 06 2016, Eli Zaretskii wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Sun, 4 Sep 2016 12:21:20 -0400
>> Cc: Aiken <acairncross@gmail.com>,
>> 	Clément Pit--Claudel <clement.pit@gmail.com>,
>> 	24091@debbugs.gnu.org
>> 
>> On Sun, Sep 4, 2016 at 11:56 AM, martin rudalics <rudalics@gmx.at> wrote:
>> > In x_make_frame_visible we have this loop:
>> >
>> >     while (!FRAME_VISIBLE_P (f))
>> >
>> > What I wanted to know is whether the frame f here is the _same_ frame
>> > you see in x_top_window_to_frame where IIUC
>> >
>> >           if (wdesc == XtWindow (x->widget))
>> >             return f;
>> 
>> Oh, I see. Yes, it is the same frame.
>
> Maybe we should stop waiting after some time has passed, like 0.5
> sec.  Does that work in this case?  Does the frame always appears
> within half a second when workspaces are not involved?
>
> Thanks.

bug#24091: 24.5; High CPU usage at startup while hidden

[npostavs]

[-- Attachment #1: Type: text/plain, Size: 547 bytes --]

tags 24091 patch
quit

Dominik Schrempf <dominik.schrempf@gmail.com> writes:

> I do not want to bring up old threads,

On the contrary, please do feel free to bring up any open bug thread.

> but I am having the exact same problem with Emacs+XMonad for years
> now.

That's interesting information, because I thought that loop was supposed
to be working for XMonad.

> Did you come to a conclusion or find a fix back in September?

We left things inconclusive, but revisiting this now, I see no reason
against simply removing this waiting loop:


[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 3651 bytes --]

From 94473fdaaf815dc2227a9e646722e1d033245b57 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs@gmail.com>
Date: Fri, 13 Jan 2017 19:47:22 -0500
Subject: [PATCH v1] Don't wait for frame to become visible

* src/xterm.c (x_make_frame_visible): Remove code that waits for the
frame to become visible.  No callers require this, and for some window
managers it doesn't work and causes Emacs to get stuck in a busy
loop (Bug#24091).
---
 src/xterm.c | 58 ++++------------------------------------------------------
 1 file changed, 4 insertions(+), 54 deletions(-)

diff --git a/src/xterm.c b/src/xterm.c
index adc02e2..db561c9 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -10993,19 +10993,12 @@ xembed_send_message (struct frame *f, Time t, enum xembed_message msg,
 \f
 /* Change of visibility.  */
 
-/* This tries to wait until the frame is really visible.
-   However, if the window manager asks the user where to position
-   the frame, this will return before the user finishes doing that.
-   The frame will not actually be visible at that time,
-   but it will become visible later when the window manager
-   finishes with it.  */
+/* This function sends the request to make the frame visible, but may
+   return before it the frame's visibility is changed.  */
 
 void
 x_make_frame_visible (struct frame *f)
 {
-  int original_top, original_left;
-  int tries = 0;
-
   block_input ();
 
   x_set_bitmap_icon (f);
@@ -11052,16 +11045,13 @@ x_make_frame_visible (struct frame *f)
      before we do anything else.  We do this loop with input not blocked
      so that incoming events are handled.  */
   {
-    Lisp_Object frame;
     /* This must be before UNBLOCK_INPUT
        since events that arrive in response to the actions above
        will set it when they are handled.  */
     bool previously_visible = f->output_data.x->has_been_visible;
 
-    XSETFRAME (frame, f);
-
-    original_left = f->left_pos;
-    original_top = f->top_pos;
+    int original_left = f->left_pos;
+    int original_top = f->top_pos;
 
     /* This must come after we set COUNT.  */
     unblock_input ();
@@ -11105,46 +11095,6 @@ x_make_frame_visible (struct frame *f)
 
 	unblock_input ();
       }
-
-    /* Process X events until a MapNotify event has been seen.  */
-    while (!FRAME_VISIBLE_P (f))
-      {
-	/* Force processing of queued events.  */
-	x_sync (f);
-
-        /* If on another desktop, the deiconify/map may be ignored and the
-           frame never becomes visible.  XMonad does this.
-           Prevent an endless loop.  */
-        if (FRAME_ICONIFIED_P (f) &&  ++tries > 100)
-          break;
-
-       /* This hack is still in use at least for Cygwin.  See
-	   http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html.
-
-	   Machines that do polling rather than SIGIO have been
-	   observed to go into a busy-wait here.  So we'll fake an
-	   alarm signal to let the handler know that there's something
-	   to be read.  We used to raise a real alarm, but it seems
-	   that the handler isn't always enabled here.  This is
-	   probably a bug.  */
-	if (input_polling_used ())
-	  {
-	    /* It could be confusing if a real alarm arrives while
-	       processing the fake one.  Turn it off and let the
-	       handler reset it.  */
-	    int old_poll_suppress_count = poll_suppress_count;
-	    poll_suppress_count = 1;
-	    poll_for_input_1 ();
-	    poll_suppress_count = old_poll_suppress_count;
-	  }
-
-	if (XPending (FRAME_X_DISPLAY (f)))
-	  {
-	    XEvent xev;
-	    XNextEvent (FRAME_X_DISPLAY (f), &xev);
-	    x_dispatch_event (&xev, FRAME_X_DISPLAY (f));
-	  }
-      }
   }
 }
 
-- 
2.9.3


[-- Attachment #3: Type: text/plain, Size: 365 bytes --]


> On Tue, Sep 06 2016, Eli Zaretskii wrote:
>>
>> Maybe we should stop waiting after some time has passed, like 0.5
>> sec.  Does that work in this case?  Does the frame always appears
>> within half a second when workspaces are not involved?

I don't think any particular timed wait can be guaranteed to work in all
cases, since this involves multiple processes.

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: npostavs@users.sourceforge.net
> Cc: Eli Zaretskii <eliz@gnu.org>,  24091@debbugs.gnu.org,  acairncross@gmail.com,  clement.pit@gmail.com
> Date: Fri, 13 Jan 2017 20:38:02 -0500
> 
> We left things inconclusive, but revisiting this now, I see no reason
> against simply removing this waiting loop:

Are you saying that the loop has no purpose at all?  If it does, what
will happen with the code which needs that loop?  E.g., AFAIK some
stuff is impossible to do without the frame actually being shown on
display.

But maybe I'm wrong.  Ken, can you comment on this, please?

bug#24091: 24.5; High CPU usage at startup while hidden

[Ken Raeburn]

On Jan 14, 2017, at 02:52, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: npostavs@users.sourceforge.net
>> Cc: Eli Zaretskii <eliz@gnu.org>,  24091@debbugs.gnu.org,  acairncross@gmail.com,  clement.pit@gmail.com
>> Date: Fri, 13 Jan 2017 20:38:02 -0500
>> 
>> We left things inconclusive, but revisiting this now, I see no reason
>> against simply removing this waiting loop:
> 
> Are you saying that the loop has no purpose at all?  If it does, what
> will happen with the code which needs that loop?  E.g., AFAIK some
> stuff is impossible to do without the frame actually being shown on
> display.
> 
> But maybe I'm wrong.  Ken, can you comment on this, please?

As I understand it, from the function’s comments and stuff I’ve read so far about the X11 and window manager protocols, the function already cannot guarantee that the window is visible when it returns, it can only request of the window manager that it make the window visible, which may or may not happen soon.  In that sense, I think Noam’s right and we could just discard the loop.

On the other hand, there are probably environments and situations (depending on the use of virtual desktops, choice of window manager, etc) where the current code does, in fact, wait for the window to appear, and won’t any more if we remove the loop.  Given that we should redraw things on expose events anyway, I’m not sure it'll matter, unless someone’s following up a call to make-frame-visible with some other action that needs to be delayed until after the window is actually visible.  I think it’s probably worth trying it to see if any differences are noticed under any of the environments people are using.

Ken

bug#24091: 24.5; High CPU usage at startup while hidden

[Eli Zaretskii]

> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 16 Jan 2017 18:36:05 -0500
> Cc: npostavs@users.sourceforge.net,
>  dominik.schrempf@gmail.com,
>  24091@debbugs.gnu.org,
>  acairncross@gmail.com,
>  clement.pit@gmail.com
> 
> > But maybe I'm wrong.  Ken, can you comment on this, please?
> 
> As I understand it, from the function’s comments and stuff I’ve read so far about the X11 and window manager protocols, the function already cannot guarantee that the window is visible when it returns, it can only request of the window manager that it make the window visible, which may or may not happen soon.  In that sense, I think Noam’s right and we could just discard the loop.
> 
> On the other hand, there are probably environments and situations (depending on the use of virtual desktops, choice of window manager, etc) where the current code does, in fact, wait for the window to appear, and won’t any more if we remove the loop.  Given that we should redraw things on expose events anyway, I’m not sure it'll matter, unless someone’s following up a call to make-frame-visible with some other action that needs to be delayed until after the window is actually visible.  I think it’s probably worth trying it to see if any differences are noticed under any of the environments people are using.

OK, let's try.

bug#24091: 24.5; High CPU usage at startup while hidden

[npostavs]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ken Raeburn <raeburn@raeburn.org>
>> Given that we
>> should redraw things on expose events anyway, I’m not sure it'll
>> matter, unless someone’s following up a call to make-frame-visible
>> with some other action that needs to be delayed until after the
>> window is actually visible.

Do we know about any operations that require the frame be visible?  What
happens when they're run with an invisible frame?  Error?  Corrupted
display?  Hang?

bug#24091: 24.5; High CPU usage at startup while hidden

[Ken Raeburn]

On Jan 17, 2017, at 21:21, npostavs@users.sourceforge.net wrote:
> 
> Do we know about any operations that require the frame be visible?  What
> happens when they're run with an invisible frame?  Error?  Corrupted
> display?  Hang?

If drawing is done to an unmapped window, the X server can discard the data, but once the window is made visible, we should get an Expose event which would cause us to repaint the window.  The size and position of the window could be set by the window manager, and dropping the loop may mean we get to run a little more code than we used to before we get notified of the changes.  But these are things we have to deal with anyway, not just at window creation.  If we’re doing it right, AFAIK, we should be okay….

Ken

bug#24091: 24.5; High CPU usage at startup while hidden

[npostavs]

merge 24091 17237
tags 24091 fixed
close 24091 26.1
quit

Ken Raeburn <raeburn@raeburn.org> writes:

> On Jan 17, 2017, at 21:21, npostavs@users.sourceforge.net wrote:
>> 
>> Do we know about any operations that require the frame be visible?  What
>> happens when they're run with an invisible frame?  Error?  Corrupted
>> display?  Hang?
>
> If drawing is done to an unmapped window, the X server can discard the
> data, but once the window is made visible, we should get an Expose
> event which would cause us to repaint the window.  The size and
> position of the window could be set by the window manager, and
> dropping the loop may mean we get to run a little more code than we
> used to before we get notified of the changes.  But these are things
> we have to deal with anyway, not just at window creation.  If we’re
> doing it right, AFAIK, we should be okay….

Okay, pushed to master [1: 6a788d2], let's see if we're doing it right.

PS Dominik I merged #17237 into this one since it appears to be the same
problem which should be fixed by this patch, please report back if it's
not.

1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
  Don't wait for frame to become visible

bug#24091: 24.5; High CPU usage at startup while hidden

[Dominik Schrempf]

Works like a charm.  So far, it didn't lead to any problems.
Thank you very much!

Dominik

On Fri, Jan 20 2017, npostavs@users.sourceforge.net wrote:
> merge 24091 17237
> tags 24091 fixed
> close 24091 26.1
> quit
>
> Ken Raeburn <raeburn@raeburn.org> writes:
>
>> On Jan 17, 2017, at 21:21, npostavs@users.sourceforge.net wrote:
>>> 
>>> Do we know about any operations that require the frame be visible?  What
>>> happens when they're run with an invisible frame?  Error?  Corrupted
>>> display?  Hang?
>>
>> If drawing is done to an unmapped window, the X server can discard the
>> data, but once the window is made visible, we should get an Expose
>> event which would cause us to repaint the window.  The size and
>> position of the window could be set by the window manager, and
>> dropping the loop may mean we get to run a little more code than we
>> used to before we get notified of the changes.  But these are things
>> we have to deal with anyway, not just at window creation.  If we’re
>> doing it right, AFAIK, we should be okay….
>
> Okay, pushed to master [1: 6a788d2], let's see if we're doing it right.
>
> PS Dominik I merged #17237 into this one since it appears to be the same
> problem which should be fixed by this patch, please report back if it's
> not.
>
> 1: 2017-01-20 23:36:26 -0500 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7
>   Don't wait for frame to become visible

bug#24091: Problem caused by the fix for this bug

[Ken Brown]

I've just discovered that the fix for this bug (commit 
6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 
build of Emacs on Cygwin.  See the comments and code near the following 
comment that was removed in that commit:

"This hack is still in use at least for Cygwin.  See
http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html."

The symptom, which I admit is purely cosmetic, is that the image at the 
top of the splash screen is not displayed on startup.  I hope the people 
who worked on this bug know how to fix this, because I don't know 
anything about how X11 and polling for input work.  If not, I'll try to 
dig into it.

Ken

bug#24091: Problem caused by the fix for this bug

[Noam Postavsky]

On Thu, Oct 26, 2017 at 1:22 PM, Ken Brown <kbrown@cornell.edu> wrote:
> I've just discovered that the fix for this bug (commit
> 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 build
> of Emacs on Cygwin

This was later modified in [1: e1f6e31]; do you see problems before
that commit, or after it (or both)?

[1: e1f6e31]: 2017-09-29 18:40:06 -0400
  Bring back the busy wait after x_make_frame_visible (Bug#25521)
  http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e1f6e3127a292e6ba66d27c49ddda4fe949569f5

bug#24091: Problem caused by the fix for this bug

[Ken Brown]

On 10/26/2017 1:42 PM, Noam Postavsky wrote:
> On Thu, Oct 26, 2017 at 1:22 PM, Ken Brown <kbrown@cornell.edu> wrote:
>> I've just discovered that the fix for this bug (commit
>> 6a788d2fc18c23dcfc5d0352649b2f690e9cbff7) causes problems on the X11 build
>> of Emacs on Cygwin
> 
> This was later modified in [1: e1f6e31]; do you see problems before
> that commit, or after it (or both)?

The commit I cited was the first bad one (as determined by git bisect). 
The problem still exists in the current HEAD of the emacs-26 branch.

Ken

bug#24091: Problem caused by the fix for this bug

[Noam Postavsky]

On Thu, Oct 26, 2017 at 2:12 PM, Ken Brown <kbrown@cornell.edu> wrote:

> The commit I cited was the first bad one (as determined by git bisect). The
> problem still exists in the current HEAD of the emacs-26 branch.

Okay. I removed the code because my understanding of the comment was
that it was needed to prevent a hang during the busy wait for
visibility. Therefore, when I removed that busy wait, I thought that
poll_for_input_1 was no longer needed either.

However, from what you say, it sounds like it's rather needed after
creating a frame, unrelated to the waiting per se. I don't really
understand what the code does, but I guess you could try putting the
poll_for_input_1 stuff back in either before, inside, or after the
x_wait_for_event at the end of x_make_frame_visible and see what
helps?

bug#24091: Problem caused by the fix for this bug

[Ken Brown]

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]

On 10/26/2017 4:40 PM, Noam Postavsky wrote:
> On Thu, Oct 26, 2017 at 2:12 PM, Ken Brown <kbrown@cornell.edu> wrote:
> 
>> The commit I cited was the first bad one (as determined by git bisect). The
>> problem still exists in the current HEAD of the emacs-26 branch.
> 
> Okay. I removed the code because my understanding of the comment was
> that it was needed to prevent a hang during the busy wait for
> visibility. Therefore, when I removed that busy wait, I thought that
> poll_for_input_1 was no longer needed either.
> 
> However, from what you say, it sounds like it's rather needed after
> creating a frame, unrelated to the waiting per se. I don't really
> understand what the code does, but I guess you could try putting the
> poll_for_input_1 stuff back in either before, inside, or after the
> x_wait_for_event at the end of x_make_frame_visible and see what
> helps?

Putting it before the x_wait_for_event fixes the problem.  Patch attached.

Eli, is it OK to push this to the release branch?

Ken

[-- Attachment #2: 0001-Fix-startup-display-on-Cygwin.patch --]
[-- Type: text/plain, Size: 1408 bytes --]

From 9160ce9d56222deb17a5c3922b66a0e8b214f751 Mon Sep 17 00:00:00 2001
From: Ken Brown <kbrown@cornell.edu>
Date: Fri, 27 Oct 2017 10:04:30 -0400
Subject: [PATCH] Fix startup display on Cygwin

* src/xterm.c (x_make_frame_visible): Restore code that forces
input to be read if input polling is used.  This is needed on
Cygwin.  (Bug#24091)
---
 src/xterm.c | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/src/xterm.c b/src/xterm.c
index d90654b101..92066e9229 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -11504,6 +11504,23 @@ x_make_frame_visible (struct frame *f)
 
     /* Try to wait for a MapNotify event (that is what tells us when a
        frame becomes visible).  */
+
+    /* This hack is still in use at least for Cygwin.  See
+       http://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00351.html
+       and https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24091#131.
+       Fake an alarm signal to let the handler know that there's
+       something to be read.  */
+    if (input_polling_used ())
+      {
+	/* It could be confusing if a real alarm arrives while
+	   processing the fake one.  Turn it off and let the
+	   handler reset it.  */
+	int old_poll_suppress_count = poll_suppress_count;
+	poll_suppress_count = 1;
+	poll_for_input_1 ();
+	poll_suppress_count = old_poll_suppress_count;
+      }
+
     x_wait_for_event (f, MapNotify);
   }
 }
-- 
2.14.2

bug#24091: Problem caused by the fix for this bug

[Eli Zaretskii]

> Cc: 24091@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> From: Ken Brown <kbrown@cornell.edu>
> Date: Fri, 27 Oct 2017 10:11:19 -0400
> 
> Eli, is it OK to push this to the release branch?

Since this a Cygwin-only problem, I'd prefer that fix will be
Cygwin-specific.  Then it will be okay for the release branch.

Thanks.

bug#24091: Problem caused by the fix for this bug

[Ken Brown]

On 10/27/2017 1:26 PM, Eli Zaretskii wrote:
> Since this a Cygwin-only problem, I'd prefer that fix will be
> Cygwin-specific.  Then it will be okay for the release branch.

OK, I've pushed it with that change.

Ken