On Wed, Mar 11, 2009 at 2:42 AM, Ken Thomases <k...@codeweavers.com> wrote: > There is, in fact, no need for a dummy input source. A timer is sufficient > to keep a run loop "running", which is to say blocked. I was one of the > incorrect folks who propagated this myth, unfortunately, but was corrected. > Either a dummy input source such as a port _or_ a timer is enough to keep a > run loop -run... method from immediately exiting.
And taken in context with the rest of the statements about how timers aren't input sources, this didn't make sense to me. > Although these details should not be relied upon, under the hood a run loop > is implemented in terms of Mach message ports. A run loop blocks by calling > mach_msg() to receive a Mach message on any of a set of ports. If there are > timers in the run loop mode, then the time interval until the next needs to > fire is passed as a timeout to the mach_msg() call. This is how a run loop > can block waiting for any source or timer. (If sources or timers are added > from another thread, which is legal with CFRunLoop but not NSRunLoop, then > the other thread needs to wake the run loop, probably by sending a message > on a Mach port set aside for that specific purpose. That port will be in > the set being waited on in mach_msg(), thus unblocking it.) And there we have it. Thank you very much for clearing up this rather significant confusion on my part. Sorry to everyone else for wasting your time. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
