Re: Alternative to Delay()
Re: Alternative to Delay()
- Subject: Re: Alternative to Delay()
- From: Chris Reed <email@hidden>
- Date: Tue, 29 Jul 2003 13:55:39 -0500
On Tuesday, Jul 29, 2003, at 01:05 US/Central, Philippe Wicker wrote:
On Tuesday, July 29, 2003, at 07:09 AM, Geoff wrote:
On Mon, 28 Jul 2003 13:24:12 -0500 Chris Reed < email@hidden > said:
But please don't do something like this synchronously. It freezes the
UI of your app, and generally makes the user experience less
pleasing. Using run loop timers or other timer mechanisms is not so
hard, really.
What I would need to have clarifed here then is what the system is
doing during a call to Delay() or MPDelayUntil() or usleep(). If it
was in fact paralysed, then yes this would be a problem and I wouldn't
use them, but I believe they don't chew up the processor while waiting
for the time interval requested to elapse so the processor is
available for other things in the meantime.
When you call usleep() for say 1 second, the thread (in your case the
UI thread) in which you made that call is waiting for this delay to end
up and then won't go back to the EventLoop for this duration of 1 sec.
Using a CFRunLoopTimer is much better because user events may still be
processed. Here is the code (from a C++ program) to setup a
CFRunLoopTimer.
A key point here is that usleep() will sleep only the thread on which
it is called. So if you have a CoreAudio IOProc running, that will
continue to work. The user just won't be able to operate any UI
elements. And if the delay is long enough, the spinning rainbow cursor
(whatever it's called) will appear, indicating the main run loop is not
responding.
-chris
Somewhere in your initialization routine:
.......
CFRunLoopTimerContext context = { 0, this, NULL, NULL, NULL };
mRunLoopTimerRef = CFRunLoopTimerCreate (
NULL, CFAbsoluteTimeGetCurrent(), 0.1, 0, 0, RunLoopTimerCallBack,
&context);
mRunLoopRef = CFRunLoopGetCurrent();
CFRunLoopAddTimer(mRunLoopRef, mRunLoopTimerRef,
kCFRunLoopCommonModes);
.......
The CFRunLoopTimer callback, it wakes up every 100 ms:
void RunLoopTimerCallBack (CFRunLoopTimerRef timer, void *info)
{
// info is the pointer that you passed in context (in that case the
'this' pointer)
......... your code ........
}
This is not the same principle as say, checking a mouse state in a
while loop which would no doubt spin around at least thousands of
times per second which would in fact monopolise the processor. In that
case nowadays we can use TrackMouseLocation in a loop which does this
without hogging the processor and is an official documentation
recommended procedure.
I don't use a private event loop, I use the Carbon Event Manager with
RunApplicationEventLoop() et al under MacOS X and if while waiting for
the tune to finish playing the user clicked on another app to do
something else they would be free to do so, I would only be making
them wait for my app until the tune finished playing.
I'm not saying I haven't considered that the user might want to do
something else in my app before the tune finishes playing and that
will involve some extra work disabling things that would conflict with
the tune playback (turning them back on when a timer reports) and
leaving the rest enabled throughout where there is no conflict, but
I'm in a development cycle and I'm looking for the friendliest
procedures I can find that will enable me to build the sophistication
of my application incrementally.
Full knowledge of what the above mentioned functions can or can't do
will enable me to make better choices in the long run.
Cheers Geoff %^>
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.