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

[Andrew Choi <akochoi@shaw.ca>]

Steven Tamm <steventamm@mac.com> 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.