From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Steven Tamm Newsgroups: gmane.emacs.devel Subject: Re: Mac OS X - Hang / C-g problem patch Date: Thu, 5 Dec 2002 08:32:16 -0800 Sender: emacs-devel-admin@gnu.org Message-ID: <1DB308BA-086F-11D7-AADA-00039390AB82@mac.com> References: NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v548) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1039106481 6949 80.91.224.249 (5 Dec 2002 16:41:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 5 Dec 2002 16:41:21 +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 18Jz3m-0001ng-00 for ; Thu, 05 Dec 2002 17:41:10 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 18JzBz-0004Ha-00 for ; Thu, 05 Dec 2002 17:49:40 +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 18Jyvz-00011c-00; Thu, 05 Dec 2002 11:33:07 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10.13) id 18Jyvk-0000wD-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 11:32:52 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18JyvE-0000f9-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 11:32:51 -0500 Original-Received: from smtpout.mac.com ([17.250.248.87]) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18JyvD-0000eg-00 for emacs-devel@gnu.org; Thu, 05 Dec 2002 11:32:19 -0500 Original-Received: from asmtp02.mac.com (asmtp02-qfe3 [10.13.10.66]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id gB5GWI8W016299 for ; Thu, 5 Dec 2002 08:32:18 -0800 (PST) Original-Received: from mac.com ([12.236.43.16]) by asmtp02.mac.com (Netscape Messaging Server 4.15) with ESMTP id H6NN9S00.HL2; Thu, 5 Dec 2002 08:32:16 -0800 Original-To: Andrew Choi In-Reply-To: X-Mailer: Apple Mail (2.548) 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:9892 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9892 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). 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? -Steven On Wednesday, December 4, 2002, at 10:48 PM, Andrew Choi wrote: > Steven Tamm writes: > >> I just found some free time on my hands and got back around to working >> on the problem where in the carbon gui, C-g does not interrupt >> synchronous subprocesses. This caused much consternation and after >> checking with some people at apple, there was no easy way. The >> alternatives were to finish my Jaguar/MT UI patch (which I won't go >> into), or to make all blocking reads be in a separate thread. [...] > > Hi Steven, > > I've checked that your patch works as advertised. > > I've worked out a simpler solution that uses polling though. The idea > is to patch `read' to call `select' to check for available input. If > none is after one second, poll for a user-cancel and check for input > again and repeat. Since I've used CheckEventQueueForUserCancel, the > command-period key is used instead of C-g. We can probably change it > to > C-g if we want. > > The patch also handles the following cases: when Emacs is stuck in a > loop executing Lisp code and when it is stuck waiting for select > instead > of read (e.g., sleep-for). > > Performance will not be a problem except perhaps for the check in > `eval'. > > Andrew.