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

[npostavs@users.sourceforge.net]

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