From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: npostavs@users.sourceforge.net Newsgroups: gmane.emacs.bugs Subject: bug#24091: 24.5; High CPU usage at startup while hidden Date: Fri, 13 Jan 2017 20:38:02 -0500 Message-ID: <87a8auzait.fsf@users.sourceforge.net> References: <24533f31-9fc2-b38e-aaeb-561616cdf77f@gmail.com> <87shut9pyk.fsf@users.sourceforge.net> <83lh0lq9n5.fsf@gnu.org> <83oa5fp1zb.fsf@gnu.org> <877fbkw7b1.fsf@users.sourceforge.net> <83inv1fnf9.fsf@gnu.org> <83zinodghv.fsf@gnu.org> <83y438de6m.fsf@gnu.org> <57CBCE4F.5040705@gmx.at> <57CC1E5F.8010107@gmx.at> <57CC4435.7040503@gmx.at> <838tv5au9g.fsf@gnu.org> <87shons1mf.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1484357904 14970 195.159.176.226 (14 Jan 2017 01:38:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 14 Jan 2017 01:38:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: acairncross@gmail.com, clement.pit@gmail.com, 24091@debbugs.gnu.org To: Dominik Schrempf Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jan 14 02:38:19 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cSDIM-0002Md-0t for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Jan 2017 02:38:14 +0100 Original-Received: from localhost ([::1]:46027 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSDIK-000686-8q for geb-bug-gnu-emacs@m.gmane.org; Fri, 13 Jan 2017 20:38:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cSDID-00066g-Cr for bug-gnu-emacs@gnu.org; Fri, 13 Jan 2017 20:38:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cSDIA-0002bx-2y for bug-gnu-emacs@gnu.org; Fri, 13 Jan 2017 20:38:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37805) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cSDI9-0002bt-Vr for bug-gnu-emacs@gnu.org; Fri, 13 Jan 2017 20:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cSDI9-0000GV-ON for bug-gnu-emacs@gnu.org; Fri, 13 Jan 2017 20:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: npostavs@users.sourceforge.net Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Jan 2017 01:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24091 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 24091-submit@debbugs.gnu.org id=B24091.1484357828945 (code B ref 24091); Sat, 14 Jan 2017 01:38:01 +0000 Original-Received: (at 24091) by debbugs.gnu.org; 14 Jan 2017 01:37:08 +0000 Original-Received: from localhost ([127.0.0.1]:53204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cSDHG-0000F5-Rc for submit@debbugs.gnu.org; Fri, 13 Jan 2017 20:37:07 -0500 Original-Received: from mail-io0-f193.google.com ([209.85.223.193]:34887) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cSDHE-0000EW-TQ; Fri, 13 Jan 2017 20:37:05 -0500 Original-Received: by mail-io0-f193.google.com with SMTP id m98so7305891iod.2; Fri, 13 Jan 2017 17:37:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=P4OC5yL5lH15RfKIfYdu1JPWsO6qKN6WyfjrJzKoZBw=; b=oB++yz3v3498f1ma6AaPhe+kGiImLiQVV+N2xNN7O7kzLALaPGe5qh6JzOg/adeLDo BZ8QQdzbwxXTSWTi3fgHss+Kn6oODIM4TysCcGqGvk6cjBkXro8rfcKsHBDXRj6oI2O1 mCezUC215SsLA7pOOQqppKOfNLapLi94LcSUcOjNzCXs11X7LQng4sMRXqsadG4+2Hvr CwpBrKdSs+vs+mp+Jgn1sqrJYXAcBsYJ9vR3fxDMmOiHbXz9LrOBDaO1o3eCHWD5THxO TlHCa2v6g6x2YZCv7q0efWXlgNPJb2GzuiGXGH5YH4jraKhtY6XKwr5Hug4YHMLJTAI1 wOPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version; bh=P4OC5yL5lH15RfKIfYdu1JPWsO6qKN6WyfjrJzKoZBw=; b=rMxlV1SLkyGGfFtxqlvXrzh794DRPEQUxLG4mrZ/FsLsOpxuqZTB3CZFVL9iCJLrWA ZAb1sE+Fss7FXWOmH7lQOjbzZtKStK4pP0qL9EUpQsj+cUkz/TZ1EldEFfws3YgW3k3K 5XCZJgqOptwl4ruerLtt4mntvfZBNrJsX0PUWOBooD3Ip54Ixv7V9LJ7PTUhZvMau1JI B352RuHGZ4PssIYBh+pceGdQF6Hexn4YHds47XkAjx3Hikx4be5LX6DHTL7JG2NOMWtM WydF/MPlfwD0Enjq9diBfPVWmizqutKDGsFMM1Paax8zTUr1I0hlUIj0BeVw21423WOw jS+Q== X-Gm-Message-State: AIkVDXLnn8LpyLYdCna84TBbyqtIPsnaTYxN3mDmjcWrLfueYJh1pXMgV4hOlOg7d/5rWA== X-Received: by 10.107.143.86 with SMTP id r83mr20444916iod.121.1484357819085; Fri, 13 Jan 2017 17:36:59 -0800 (PST) Original-Received: from zony ([45.2.7.65]) by smtp.googlemail.com with ESMTPSA id o13sm1892678ith.5.2017.01.13.17.36.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Jan 2017 17:36:58 -0800 (PST) In-Reply-To: <87shons1mf.fsf@gmail.com> (Dominik Schrempf's message of "Fri, 13 Jan 2017 11:19:52 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:128095 Archived-At: --=-=-= Content-Type: text/plain tags 24091 patch quit Dominik Schrempf 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: --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=v1-0001-Don-t-wait-for-frame-to-become-visible.patch Content-Description: patch >From 94473fdaaf815dc2227a9e646722e1d033245b57 Mon Sep 17 00:00:00 2001 From: Noam Postavsky 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, /* 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 --=-=-= Content-Type: text/plain > 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. --=-=-=--