From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: sit-for Date: Sat, 29 Jul 2006 10:43:53 -0400 Message-ID: <87vepgii8m.fsf@stupidchicken.com> References: <854px1e8xx.fsf@lola.goethe.zz> <87d5bppfid.fsf@stupidchicken.com> <85wt9wq3u1.fsf@lola.goethe.zz> <85k65wpzwr.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 1154184290 6246 80.91.229.2 (29 Jul 2006 14:44:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 29 Jul 2006 14:44:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 29 16:44:47 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 1G6q3b-0000GC-01 for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2006 16:44:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6q3a-0003gX-Fl for ged-emacs-devel@m.gmane.org; Sat, 29 Jul 2006 10:44:46 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6q2r-0003Ls-T4 for emacs-devel@gnu.org; Sat, 29 Jul 2006 10:44:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6q2r-0003LV-8l for emacs-devel@gnu.org; Sat, 29 Jul 2006 10:44:01 -0400 Original-Received: from [18.72.1.2] (helo=south-station-annex.mit.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G6q55-0007i1-IS; Sat, 29 Jul 2006 10:46:19 -0400 Original-Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6TEhxJH023190; Sat, 29 Jul 2006 10:43:59 -0400 (EDT) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by grand-central-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6TEhx8n024603; Sat, 29 Jul 2006 10:43:59 -0400 (EDT) Original-Received: from cyd (SYDNEYPACIFIC-FOUR-SIXTY-SEVEN.MIT.EDU [18.95.6.212]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id k6TEhqDg014509; Sat, 29 Jul 2006 10:43:53 -0400 (EDT) Original-Received: from cyd by cyd with local (Exim 3.36 #1 (Debian)) id 1G6q2j-0000lX-00; Sat, 29 Jul 2006 10:43:53 -0400 Original-To: David Kastrup In-Reply-To: <85k65wpzwr.fsf@lola.goethe.zz> (David Kastrup's message of "Sat, 29 Jul 2006 10:40:20 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Spam-Score: 1.47 X-Scanned-By: MIMEDefang 2.42 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:57785 Archived-At: > 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. My guess is that it's a `sit-for' call in the jit-lock stealth timer causing the problem. There are two places in read_char that could conceivably carry out some expensive operations while waiting for input. I doubt these are the culprits, but to rule them out, could you apply the following patch and see if the problem still occurs? Apart from that, there are two other possibilities I can think of that may cause this kind of trouble. The first is that some invalid "input event" is continuously firing, causing wait_reading_process_output to return instantly. Since kbd_buffer_get_event loops calling wait_reading_process_output until it gets a valid event, this could cause high CPU consumption. If this is indeed the case, we'll probably have to somehow fix wait_read_process_output itself to ignore those fake events (which makes the entire strategy of the Lisp-level sit-for redundant). The other possibility is some kind of bad timer interaction, in which a timer is called during sit-for, but that timer itself contains a sit-for, so each sit-for never returns. But that kind of bug would probably have affected the old sit-for implementation too, so this seems unlikely. *** emacs/src/keyboard.c.~1.861.~ 2006-07-28 09:21:33.000000000 -0400 --- emacs/src/keyboard.c 2006-07-29 10:06:29.000000000 -0400 *************** *** 2556,2561 **** --- 2556,2570 ---- /* Normal case: no input arrived during redisplay. */ break; + /* Don't keep looping if the timeout expires. */ + if (end_time) + { + EMACS_TIME now; + EMACS_GET_TIME (now); + if (EMACS_TIME_GE (now, *end_time)) + goto exit; + } + /* Input arrived and pre-empted redisplay. Process any events which are not user-visible. */ swallow_events (0); *************** *** 2749,2755 **** /* Maybe autosave and/or garbage collect due to idleness. */ ! if (INTERACTIVE && NILP (c)) { int delay_level, buffer_size; --- 2758,2764 ---- /* Maybe autosave and/or garbage collect due to idleness. */ ! if (INTERACTIVE && NILP (c) && !end_time) { int delay_level, buffer_size;