From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: YAMAMOTO Mitsuharu Newsgroups: gmane.emacs.devel Subject: alarm_signal_handler is called too frequently Date: Wed, 13 Oct 2004 10:15:53 +0900 Organization: Faculty of Science, Chiba University Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Trace: sea.gmane.org 1097630201 14406 80.91.229.6 (13 Oct 2004 01:16:41 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 13 Oct 2004 01:16:41 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Oct 13 03:16:34 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CHXko-0005J9-00 for ; Wed, 13 Oct 2004 03:16:34 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CHXrp-0000X7-3Z for ged-emacs-devel@m.gmane.org; Tue, 12 Oct 2004 21:23:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CHXri-0000Wb-LR for emacs-devel@gnu.org; Tue, 12 Oct 2004 21:23:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CHXri-0000WH-8J for emacs-devel@gnu.org; Tue, 12 Oct 2004 21:23:42 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CHXri-0000WE-18 for emacs-devel@gnu.org; Tue, 12 Oct 2004 21:23:42 -0400 Original-Received: from [133.82.132.2] (helo=mathmail.math.s.chiba-u.ac.jp) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CHXkE-0003ZT-Rn for emacs-devel@gnu.org; Tue, 12 Oct 2004 21:16:00 -0400 Original-Received: from church.math.s.chiba-u.ac.jp (church [133.82.132.36]) by mathmail.math.s.chiba-u.ac.jp (Postfix) with ESMTP id 5608C1A6395 for ; Wed, 13 Oct 2004 10:15:53 +0900 (JST) Original-To: emacs-devel@gnu.org User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI) 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: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:28327 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:28327 I noticed that alarm_signal_handler was called too frequently on the system that used polling with SIGALRM (such as Solaris/X11 and Mac OS X/Carbon). In alarm_signal_handler, set_alarm is called even when interrupt_input_blocked is non-zero where no timer function is executed. If BLOCK_INPUT continues for a long time, which is typical in Mac OS X/Carbon, set_alarm will set the timer value to 1000 usec because the current time (now) exceeds the old expiration time (atimers->expiration). I think we don't have to call set_alarm when pending_atimers is non-zero because do_pending_atimers is supposed to be called eventually in such a case. Is that correct? The following patch also apparently reduces the CPU usage during the idle time (~1.0% -> 0.0% on my PowerBook G4 667MHz). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp Index: src/atimer.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/atimer.c,v retrieving revision 1.16 diff -c -r1.16 atimer.c *** src/atimer.c 19 Jul 2004 04:42:43 -0000 1.16 --- src/atimer.c 13 Oct 2004 00:56:47 -0000 *************** *** 397,403 **** EMACS_GET_TIME (now); } ! set_alarm (); } --- 397,404 ---- EMACS_GET_TIME (now); } ! if (!pending_atimers) ! set_alarm (); }