From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chetan Pandya Newsgroups: gmane.emacs.devel Subject: Re: Pretest next week Date: Wed, 28 Jan 2009 19:39:55 -0800 (PST) Message-ID: <457509.56586.qm@web83207.mail.mud.yahoo.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1233200421 3245 80.91.229.12 (29 Jan 2009 03:40:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 29 Jan 2009 03:40:21 +0000 (UTC) Cc: Chong Yidong , Jason Rumney , emacs-devel@gnu.org To: Stefan Monnier , Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 29 04:41:34 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 1LSNmR-0001dS-La for ged-emacs-devel@m.gmane.org; Thu, 29 Jan 2009 04:41:28 +0100 Original-Received: from localhost ([127.0.0.1]:54071 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSNl8-0006XU-So for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2009 22:40:06 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LSNl3-0006XE-51 for emacs-devel@gnu.org; Wed, 28 Jan 2009 22:40:01 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LSNl0-0006Vx-Eb for emacs-devel@gnu.org; Wed, 28 Jan 2009 22:40:00 -0500 Original-Received: from [199.232.76.173] (port=50543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LSNl0-0006Vp-9I for emacs-devel@gnu.org; Wed, 28 Jan 2009 22:39:58 -0500 Original-Received: from web83207.mail.mud.yahoo.com ([216.252.101.63]:21612) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1LSNkz-0001Cf-Nh for emacs-devel@gnu.org; Wed, 28 Jan 2009 22:39:58 -0500 Original-Received: (qmail 56633 invoked by uid 60001); 29 Jan 2009 03:39:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=BvgPAwcKZyUUmJj/F7M7skK0lgE0v33XAVvw3gp0eBu9hQd+/0aSs8rwNEE+4LAdFPoy/Y10flVFRG6Uz4Pa0vX6/ThHZ8cRBX8RlJZpeUl1BPZUx0vPPdviUvYxk8kojYnfdk2MpyoFWDd3Z+u0AWT+kY0cqBvYwKenftOvZgw=; X-YMail-OSG: hQ_6IPMVM1mdKl5SuMzulfVDZISI3JkD9CAsZEJl0NQKSd_5HXggYQwkDNFCd5rsUdBRd0kZVACzsHqJSUM8KaZk_Mnx.3L0k_Yb1LIM2_p2CniaTDT8zEn1sGzU7tg22GUnJlljksqjJxO4z.UxaeW2HKYC022a7QCbeL4o3YapvsDAC.vmTHWOkWIS.RlfWh35e_oitDUnujFuCCo- Original-Received: from [75.36.178.29] by web83207.mail.mud.yahoo.com via HTTP; Wed, 28 Jan 2009 19:39:55 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) 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:108352 Archived-At: From: Stefan Monnier > Yes, adding > else if (pending_atimers) \ > do_pending_atimers(); \ > at the end of QUIT allows poll_timer() to fire under SYNC_INPUT and Ctrl-g > to be detected, with no apparent other ill effects (in very limited > testing). Good. >> If so, we should probably create a new >> var `pending_signals', which should always reflect >> "pending_timers || interrupt_input_pending" > I'm not sure if the extra 0-comparison would significantly add to overhead > but I guess code size could take a hit. It's easy for the CPU to predict those jumps, but I still think the current QUIT is already pretty costly, so I'd rather not make it worse. > Though maybe the part of QUIT above (when there is a quit_flag) could > also be reduced to a function call to slim things down? Yes, that would be good as well. Stefan ---------------- I am not sure code size is really an issue. Emacs executable is already huge. On the other hand, merging flags set by different signal handlers is a problem. It is quite possible for a signal handler to fire when another signal handler is running, unless other signals have been blocked. This can interfere with setting of those flags. It is perhaps safer to leave the flags separate. Other option is to block all signals that can interfere, possibly using sigaction() instead of signal(), but I am not sure of availability on all supported platforms. Chetan