From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Pretest next week Date: Wed, 28 Jan 2009 12:40:12 -0500 Message-ID: References: <87y6x4ue2u.fsf@cyd.mit.edu> <87mydjv4bd.fsf@cyd.mit.edu> <08054F25-1F90-4795-9FFE-01363F6900CE@gmail.com> <497E6D32.9000707@gnu.org> <87tz7kawln.fsf@cyd.mit.edu> <4980268C.9020104@gnu.org> <3765D6BE-634B-4D1E-AF8B-7822957F88C7@gmail.com> <6634D95E-39A0-410C-8F28-065D997D5208@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233165631 27476 80.91.229.12 (28 Jan 2009 18:00:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2009 18:00:31 +0000 (UTC) Cc: Chong Yidong , Jason Rumney , emacs-devel@gnu.org To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 28 19:01:38 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1LSEjC-0006go-3R for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2009 19:01:30 +0100 Original-Received: from localhost ([127.0.0.1]:54505 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSEhu-000218-6b for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2009 13:00:10 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSEOn-0004SA-NB for emacs-devel@gnu.org; Wed, 28 Jan 2009 12:40:25 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSEOm-0004Qy-0d for emacs-devel@gnu.org; Wed, 28 Jan 2009 12:40:25 -0500 Original-Received: from [199.232.76.173] (port=42380 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSEOl-0004QZ-Mk for emacs-devel@gnu.org; Wed, 28 Jan 2009 12:40:23 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:44287) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LSEOi-0005yB-EV; Wed, 28 Jan 2009 12:40:20 -0500 Original-Received: from alfajor.home (vpn-132-204-232-45.acd.umontreal.ca [132.204.232.45]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id n0SHeCBK015886; Wed, 28 Jan 2009 12:40:12 -0500 Original-Received: by alfajor.home (Postfix, from userid 20848) id AC89B1C14C; Wed, 28 Jan 2009 12:40:12 -0500 (EST) In-Reply-To: <6634D95E-39A0-410C-8F28-065D997D5208@gmail.com> (Adrian Robert's message of "Wed, 28 Jan 2009 18:24:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3199=0 X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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:108331 Archived-At: > As it turns out, this isn't needed. SIGALRM is triggering > alarm_signal_handler() in atimer.c correctly, but run_timers() never gets > called under SYNC_INPUT. I don't fully understand why or where the problem > is here. But undefining SYNC_INPUT gets poll_for_input() called (and hence > Ctrl-g detected) even in tight loops, with no ill effects so far. I wrote SYNC_INPUT specifically for X11 input handling. From what you say above, there is apparently a bug in the way it handles SIGALRM. Apparently the QUIT macro should check pending_atimers somehow. Can you try to tweak QUIT so it does else if (pending_atimers) run_timers; to see if it fixes your problem? If so, we should probably create a new var `pending_signals', which should always reflect "pending_timers || interrupt_input_pending", then QUIT can check this var, and if set, it can call a new function `process_pending_signals' which will then look at pending_timers and interrupt_input_pending to figure out which function(s) to call. pending_timers and process_pending_timers are desired/needed to reduce the code-size (the QUIT macro is expanded at many places), as well as to reduce the polling overhead. Stefan