From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: sit-for Date: Sat, 29 Jul 2006 10:40:20 +0200 Message-ID: <85k65wpzwr.fsf@lola.goethe.zz> References: <854px1e8xx.fsf@lola.goethe.zz> <87d5bppfid.fsf@stupidchicken.com> <85wt9wq3u1.fsf@lola.goethe.zz> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1154162447 21253 80.91.229.2 (29 Jul 2006 08:40:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Jul 2006 08:40:47 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 29 10:40:44 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G6kNA-0005j5-QB for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2006 10:40:37 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6kNA-0000cN-BK for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2006 04:40:36 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6kMz-0000cI-Vj for emacs-devel@gnu.org; Sat, 29 Jul 2006 04:40:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6kMz-0000c6-FM for emacs-devel@gnu.org; Sat, 29 Jul 2006 04:40:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6kMz-0000c3-Bh for emacs-devel@gnu.org; Sat, 29 Jul 2006 04:40:25 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6kPA-00087z-8D for emacs-devel@gnu.org; Sat, 29 Jul 2006 04:42:40 -0400 Original-Received: from localhost ([127.0.0.1] helo=lola.goethe.zz) by fencepost.gnu.org with esmtp (Exim 4.34) id 1G6kMy-0008WD-NJ; Sat, 29 Jul 2006 04:40:24 -0400 Original-Received: by lola.goethe.zz (Postfix, from userid 1002) id 709E11C000B3; Sat, 29 Jul 2006 10:40:20 +0200 (CEST) Original-To: Chong Yidong In-Reply-To: <85wt9wq3u1.fsf@lola.goethe.zz> (David Kastrup's message of "Sat, 29 Jul 2006 09:15:34 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:57773 Archived-At: David Kastrup writes: > Chong Yidong writes: > >> David Kastrup writes: >> >>> Since we have the new sit-for implementation, I have a lot of times >>> when Emacs just pauses in busy waiting for input. This happens >>> spontaneously. One situation where it happens frequently is when >>> reading news with gnus. >> >> I haven't seen this problem in my usage of gnus. > > It is not just gnus. And it is not easy to see: Emacs gets somewhat > sluggish, sometimes the cursor blinks quite less than expected, and > CPU usage goes up, up, up, which is of course mostly noticeable when > you have power management, and the fans start waking up. > >> It would be helpful if you could be more specific: does the problem >> happen with the 2006-07-26 change to `read-event'? > > Already before. I have now recompiled Emacs and will see whether this > changes something. Update: it still happens. I am working for a while in a web browser, suddenly the fans engage, the Emacs frame (not even mapped when this happens) shows a very slow and erratically blinking cursor, and `top' shows that Emacs is consuming close to 100% of CPU power. So yes, even an off-screen Emacs sitting idle in some frame suddenly decides to suck up all CPU power. >> If so, did it start to happen at that time, or did it already >> happen after the Lisp-level `sit-for' was implemented? >> >> If it only started after the `read-event' change, one possibility >> is that read_char is getting stuck somewhere before we get to the >> point where we check if the timeout has elapsed. >> >>> This is really a nuisance. The change to sit-for is a fundamental >>> change to some core mechanism of Emacs, and it is currently >>> seemingly breaking quite a few things, apart from causing strange >>> effects. >> >> That's the story of the Emacs 22 feature freeze. I can't remember any change as invasive as that without a correspondingly bad bug it was trying to fix. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum