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

[Steven Tamm <steventamm@mac.com>]

>> <polling for events in eval>
>
> 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.

Polling is not bad in the select/read case, and it probably should be 
checked in (once I get the answer from the carbon-development list 
about FindSpecificEventInQueue).  As for the test in eval, I'll run the 
profiler on it this weekend and see how much it adds to the overall 
cost of eval.

For the list, What would be a good simple-to-execute lisp function to 
profile to measure changes to Feval?  I was going to use regexp-opt.

>> <stuff about hotkeys>
>
> 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 :-).

It works a little differently than this.  The global hotkey is only 
sent to the application that requests it.  The problem is that while 
the hotkey is registered, it is NEVER sent to any other application.  
So it won't work (because not passing C-g to the terminal application 
is unacceptable).