[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X - Hang / C-g problem patch

From: Steven Tamm
Subject: Re: Mac OS X - Hang / C-g problem patch
Date: Thu, 5 Dec 2002 08:32:16 -0800

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?


On Wednesday, December 4, 2002, at 10:48  PM, Andrew Choi wrote:

Steven Tamm <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]