From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: alarm_signal_handler is called too frequently Date: Fri, 29 Oct 2004 09:00:14 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <4181EA7E.2020309@swipnet.se> References: <7E7ABFB6-2693-11D9-9BC4-000D93505B76@swipnet.se> <41813425.2010001@swipnet.se> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1099033267 25245 80.91.229.6 (29 Oct 2004 07:01:07 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 29 Oct 2004 07:01:07 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 29 09:00:55 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 1CNQko-0007iY-00 for ; Fri, 29 Oct 2004 09:00:54 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNQse-0006iQ-Mv for ged-emacs-devel@m.gmane.org; Fri, 29 Oct 2004 03:09:00 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNQsX-0006iK-Tj for emacs-devel@gnu.org; Fri, 29 Oct 2004 03:08:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNQsX-0006hw-1i for emacs-devel@gnu.org; Fri, 29 Oct 2004 03:08:53 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNQsW-0006ht-UZ for emacs-devel@gnu.org; Fri, 29 Oct 2004 03:08:52 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNQkc-0000Lg-Ry; Fri, 29 Oct 2004 03:00:43 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep02.bredband.com with ESMTP id <20041029070041.SFSQ44.mxfep02.bredband.com@coolsville.localdomain>; Fri, 29 Oct 2004 09:00:41 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040916 X-Accept-Language: en-us, en Original-To: YAMAMOTO Mitsuharu In-Reply-To: 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:29132 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29132 YAMAMOTO Mitsuharu wrote: > There may be some confusion between two kinds of timers: the OS-level > alarm timer and the Emacs-level (cooperative?) timer. The timer for > Xt timeout events is the former, and the cursor blinking uses the > latter. The function timer_check is also for the latter. Sorry, I misunderstood. The timer_check is not run from popup_get_selection for popup menus because the argument do_timers is 0: if (do_timers && !XtAppPending (Xt_app_con)) timer_check (1); But for dialogs, do_timer is 1, so timers do get checked when a dialog is popped up. However, idle timers are disabled because the event that popups the dialog makes Emacs non-idle. But non-idle timers are run. The check for INPUT_BLOCKED_P proposed by Richard in Feval does detect this: if (handling_signal || INPUT_BLOCKED_P) abort (); I guess we just have to get rid of the call to timer_check in popup_get_selection. > >>Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler >>just reschedules the alarm without running any timer code. > > > Actually, the signal handler only sets the interval timer value > (set_alarm) without calling schedule_atimer in this situation. The > new interval may become a small value, 1msec, by the following code in > set_alarm. > > /* Don't set the interval to 0; this disables the timer. */ > if (EMACS_TIME_LE (atimers->expiration, now)) > { > EMACS_SET_SECS (time, 0); > EMACS_SET_USECS (time, 1000); > } > > bzero (&it, sizeof it); > it.it_value = time; > setitimer (ITIMER_REAL, &it, 0); By "reschedules the alarm" I meant that the code arranges for another SIGALRM to be delivered. And yes, the time is 1 millisecond. > > That's the reason why I did the following question: > > 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? You mean like this? Index: atimer.c *** atimer.c.~1.16.~ 2004-07-19 12:53:25.000000000 +0200 --- atimer.c 2004-10-29 08:56:37.000000000 +0200 *************** *** 397,402 **** --- 397,403 ---- EMACS_GET_TIME (now); } + if (! (pending_atimers && interrupt_input_blocked)) set_alarm (); } That works and should save a couple of CPU cycles. Jan D.