Re: Run Loops
Re: Run Loops
- Subject: Re: Run Loops
- From: Vincent Predoehl <email@hidden>
- Date: Wed, 25 Jul 2001 13:32:07 -0400
Douglas Davidson wrote:
>
>
If you are working within a Cocoa or Carbon Event-based application, you
>
usually will not need to run the run loop yourself, at least on the main
>
thread, because the frameworks will be doing it for you as part of their
>
normal event handling. In this case what you would wish to do is to
>
create sources and add them to the run loop for the main thread; then
>
you will get a notification in the form of a callback when the thing you
>
are waiting for happens, on the main thread, within the main event
>
loop. If you are not within the context of a Cocoa or Carbon
>
Event-based application, or if you are working on another thread, then
>
you can still use that thread's run loop, but you would need to run it
>
yourself--that is, tell it to start waiting for things to happen.
We are not within the context of a Cocoa or Carbon application. Our
component was compiled from our AIX code base, so it works with pthreads,
POSIX sockets, etc. There is absolutely no Carbon or Cocoa in this
particular code component, and we would like to keep it that way, if
possible.
>
The simplest thing you can wait for on a run loop is just the arrival of
>
a specific time. There are higher-level APIs for this, but it can also
>
be done at the CF level with a CFRunLoopTimer. The way this works is
>
that each timer has a specific time, or a sequence of repeating times,
>
at which it is supposed to fire--i.e., generate a callback. When the
>
run loop is waiting, it checks to see whether the time has arrived for
>
any timer attached to it, and if so that timer's callback is sent. Note
>
that this only happens while the run loop is waiting; this is not a
>
real-time mechanism, and if you spend significant amounts of time
>
processing rather than waiting in the run loop, or if your application
>
is not scheduled for some time, timer firings will be delayed.
>
>
Run loops also have something called modes. It may not be desirable to
>
wait for every class of occurrences at all times. For example, you may
>
not wish to have a specific timer fire while the application is tracking
>
mouse moves. When a source is added to a run loop, it is added to a
>
specific mode or set of modes, or to the set of so-called "common"
>
modes. When the run loop is run, it is run with a particular mode, and
>
only those sources added for that mode are active. For Cocoa
>
applications, the common modes are: the default mode, used most of the
>
time; the event tracking mode, used when tracking mouse moves; and the
>
modal panel mode, used when a modal panel is up.
>
>
This is a general conceptual overview; I can probably be more specific
>
if there are more specific questions about exactly how to add a source
>
to a run loop.
I do have a few specific questions that have been unanswered for some time.
Like I said, our code component is meant to be a UNIX-style application.
Except for the CoreAudio framework, we have absolutely nothing to do with
Cocoa. Apparently we need to establish a run loop for CoreAudio to work
with. We set HAL's run loop to the result of CFRunLoopGetCurrent(), which
we don't know anything about. We also make this call in a loop that polls a
audio property values until it reaches the desired value:
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0.1, false); // sleep
100 millisecs
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().
Vincent
| References: | |
| | >Re: Run Loops (From: Douglas Davidson <email@hidden>) |