Re: Run Loops
Re: Run Loops
- Subject: Re: Run Loops
- From: Chris Kane <email@hidden>
- Date: Thu, 26 Jul 2001 18:24:50 -0700
On Wednesday, July 25, 2001, at 10:32 AM, Vincent Predoehl wrote:
We have been avoiding adding run loop code in our engine's main loop
because
this is meant to be a UNIX application, if possible. I guess the best
question to ask at this point is what does calling CFRunLoopRunInMode
do for
us, and does it need to be called on a regular basis? We have no other
Cocoa calls other than CFRunLoopGetCurrent() and CFRunLoopRunInMode().
Kind of a vague question, but I can give you a vague answer...
CoreAudio is using CFRunLoop to wait for and deliver messages, probably
from the kernel, about things that are going on with sound play/record
whatever. I don't know anything about CoreAudio, but that's what the
run loop is for, so if they're telling you to run the run loop if you
use the CoreAudio APIs, that is probably what's going on. The messages
from the kernel are probably being delivered to the CoreAudio framework
itself (like maybe there is a "need next data buffer" message); they're
likely not for your direct benefit, but CoreAudio's use (and then
CoreAudio probably gives you a callback in response to receiving the
message).
CFRunLoopRunInMode() is the call that "runs the run loop" or services
the input sources that have been put in the run loop. It's like using
select() on a bunch of descriptors, or waitpid() on a pid, or
WaitNextEvent() in Carbon, or whatever. The difference is that when
something happens, the run loop does the callout directly from inside of
CFRunLoopRunInMode(), then returns to you, rather than returning
information about what happened and having you do the dispatch work.
Input sources registered with the run loop are only "monitored" while
the run loop is being run (that is, the thread is blocked in the run
loop). While the run loop is not being run, things are just queueing up
(or, failing on the send side when the queues get full).
So, if you don't run the run loop often, a message about needing the
next sound data buffer (using the example from above) from the kernel
driver will sit in a queue until you do run the run loop, and sound
playback might have crackling or blanks if the next buffer isn't
delivered soon enough because the message languished. In the case of
sound play (record is even worse) it is important to respond to these
things quickly and in a timely fashion, so most of the time in your
engine should be spent in the run loop waiting for these things so that
CoreAudio gets them as quickly as possible.
Chris Kane
Cocoa Frameworks (and CoreFoundation), Apple
| References: | |
| | >Re: Run Loops (From: Vincent Predoehl <email@hidden>) |