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: Thu, 28 Oct 2004 20:02:13 +0200 Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Message-ID: <41813425.2010001@swipnet.se> References: <7E7ABFB6-2693-11D9-9BC4-000D93505B76@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 1098986603 18287 80.91.229.6 (28 Oct 2004 18:03:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 28 Oct 2004 18:03:23 +0000 (UTC) Cc: mituharu@math.s.chiba-u.ac.jp, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 28 20:03:09 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 1CNEc9-0001Ol-00 for ; Thu, 28 Oct 2004 20:03:09 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNEjx-0004mg-Fp for ged-emacs-devel@m.gmane.org; Thu, 28 Oct 2004 14:11:13 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CNEjq-0004mP-G3 for emacs-devel@gnu.org; Thu, 28 Oct 2004 14:11:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CNEjp-0004lx-JD for emacs-devel@gnu.org; Thu, 28 Oct 2004 14:11:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CNEjp-0004ls-GK for emacs-devel@gnu.org; Thu, 28 Oct 2004 14:11:05 -0400 Original-Received: from [195.54.107.73] (helo=mxfep02.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CNEbh-0002RA-CK; Thu, 28 Oct 2004 14:02:41 -0400 Original-Received: from coolsville.localdomain ([83.226.180.220] [83.226.180.220]) by mxfep02.bredband.com with ESMTP id <20041028180239.OFKQ44.mxfep02.bredband.com@coolsville.localdomain>; Thu, 28 Oct 2004 20:02:39 +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: rms@gnu.org 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:29118 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:29118 Richard Stallman wrote: > so popup_get_selection is not used for the non-toolkit build at all. > > That means item 3 is not a real problem. That is good. > > > 2. However, popup_get_selection is called inside BLOCK_INPUT, and it > > calls timer_check, which can call Lisp code. This seems to be a bug. > > I still think that is a real problem. > > It craches, but directly at start before any interaction. Disabling the > toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does > not > crash on any popup menu. > > 1. If it does not crash with popup menus, that could be because no > timer was running. Were there any timers that should have run? Maybe > something else disables the running of timers from > popup_get_selection. In that case, there is no bug here, but the code > to check timers is misleading. Timers are running (scheduled), The version that uses Xt has a timer that runs every 0.1 seconds, and I also have a blinking cursor. But see below. > > 2. Is popup_get_selection used, the way you compiled Emacs? I tried it both ways, i.e. Emacs compiled with Lucid/Motif and GTK/no toolkit. The reason no timers are actualy run is this code in alarm_signal_handler in atimer.c: while (atimers && (pending_atimers = interrupt_input_blocked) == 0 && EMACS_TIME_LE (atimers->expiration, now)) ... Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler just reschedules the alarm without running any timer code. > > 3. Can you debug the crash that does happen? I think anything that > causes a crash with this patch has the potential to cause crashes > occasionally even without this patch. It is because of this code in update_tool_bar, xdisp.c: /* Build desired tool-bar items from keymaps. */ BLOCK_INPUT; f->tool_bar_items = tool_bar_items (f->tool_bar_items, &f->n_tool_bar_items); UNBLOCK_INPUT; The BLOCK/UNBLOCK_INPUT is needed for the GTK version. This was discussed here http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html The solution proposed was to do as the menu code does, first build the structures from Lisp code, then update the GUI. Only the second stage needs to block input. Unfortunately this has not been done yet (on my todo list). Jan D.