From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andrew Choi Newsgroups: gmane.emacs.devel Subject: Re: Mac OS X - Hang / C-g problem patch Date: Thu, 05 Dec 2002 16:47:19 -0700 Sender: emacs-devel-admin@gnu.org Message-ID: References: <1DB308BA-086F-11D7-AADA-00039390AB82@mac.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT X-Trace: main.gmane.org 1039132696 630 80.91.224.249 (5 Dec 2002 23:58:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2002 23:58:16 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18K5sl-0000A1-00 for ; Fri, 06 Dec 2002 00:58:15 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18K617-0008R8-00 for ; Fri, 06 Dec 2002 01:06:53 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18K5ku-0006W7-00; Thu, 05 Dec 2002 18:50:08 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18K5kb-0006Tm-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 18:49:49 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18K5k5-00068O-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 18:49:48 -0500 Original-Received: from shawidc-mo1.cg.shawcable.net ([24.71.223.10] helo=pd4mo2so.prod.shaw.ca) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18K5k5-000687-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 18:49:17 -0500 Original-Received: from pd3mr2so.prod.shaw.ca (pd3mr2so-ser.prod.shaw.ca [10.0.141.178]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H6O006BQ7EYYN@l-daemon> for emacs-devel@gnu.org; Thu, 05 Dec 2002 16:47:22 -0700 (MST) Original-Received: from pn2ml8so.prod.shaw.ca (pn2ml8so-qfe0.prod.shaw.ca [10.0.121.152]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H6O00GJ47EYZZ@l-daemon> for emacs-devel@gnu.org; Thu, 05 Dec 2002 16:47:22 -0700 (MST) Original-Received: from owlbear.local.shawmail (h68-144-207-94.cg.shawcable.net [68.144.207.94]) by l-daemon (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 12 2002)) with ESMTP id <0H6O00LP27EXF9@l-daemon> for emacs-devel@gnu.org; Thu, 05 Dec 2002 16:47:22 -0700 (MST) In-reply-to: <1DB308BA-086F-11D7-AADA-00039390AB82@mac.com> Original-To: Steven Tamm User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 Original-Lines: 39 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9911 Steven Tamm writes: > I thought about doing it this way, because I wanted to avoid polling. > And the call to CheckEventQueueForUserCancel I didn't even bother > trying because to get C-g to work in the same manner would be quite > expensive. (To do it you would have to put in a call to RNE() for a > non-existent event type before calling FindSpecificEventsInQueue). Hi Steven, I'm not sure it will be much worse than CheckEventQueueForUserCancel unless we code it up and run a profiler on it. Most likely, the event queue will just be empty most of the time we check it. Polling the event queue every time through eval will no doubt cost an overhead. Polling is not a bad solution to detect the cancel key in `select' and `read' though. > There is also a third way. Use osx's global hotkeys. The good/bad > thing about global hotkeys is that the events are sent to every > application that cares regardless of whether they were the frontmost > application. Fork off a process that registers C-g as a global > hotkey. Whenever that process gets the hotkey and its parent app is > the frontmost process, send a kill(SIGINT). I sent this to the carbon > list yesterday and am waiting for the guy from apple to respond. If > this works with little hassle, I would prefer this solution. This > would work in all circumstances and would not require putting in > patches everywhere to check if C-g is on the system queue. > > What do you think? That doesn't seem like a good solution: an event that every application sees? But please do let me know what additional information you can get from the carbon mailing list. In terms of program architecture and efficiency, your very first attempt was the best: using a separate thread to capture all input and pass that on to a main thread. But hey I'm not working on it, so I really shouldn't be saying anything :-). Andrew.