[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: 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 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).

reply via email to

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