|
From: | Steven Tamm |
Subject: | Re: Mac OS X - Hang / C-g problem patch |
Date: | Fri, 6 Dec 2002 10:15:18 -0800 |
<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 applicationsees? But please do let me know what additional information you can getfrom 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).
[Prev in Thread] | Current Thread | [Next in Thread] |