Re: NSRunLoop looping more than once?
Re: NSRunLoop looping more than once?
- Subject: Re: NSRunLoop looping more than once?
- From: Chris Kane <email@hidden>
- Date: Tue, 18 Mar 2003 17:01:23 -0800
Furthermore, while calling [NSTimer invalidate] does stop the timer
from firing, the [NSRunLoop runMode: beforeDate] still does not
return. However, a non-repeating NSTimer appears to act like a normal
"input" to NSRunLoop in that [NSRunLoop runMode: beforeDate] does
return after the timer fires.
I find this to be bizarre. The first sentence implies that there are
further input sources in the run loop which it continues waiting on.
Yet the second sentence is a strange behavior. There's probably a bug
here (or something very subtle going on, like calling NSLog() can
change the run loop's state, so if you do that in one test and not
another, you might see different behavior).
(4) For a number of reasons, calling CFRunLoopStop (as you suggest) is
probably not the best solution to the dealing with the fact that
[NSRunLoop runMode: beforeDate] does not return from repeating
NSTimers.
CFRunLoopStop() also will not have the desired effect if the run loop
is in a recursive activation (like the running of a modal panel, or for
any other random reason).
Again as previously indicated by Chris Kane, using [NSRunLoop
acceptInputForMode: beforeDate:[NSRunLoop limitDateForMode:]] is the
way this is "supposed to be done." So, the preferred way to cleanly
exit from a NSRunLoop driving by a repeating NSTimer is like so:
while(running)[[NSRunLoop currentRunLoop]
acceptInputForMode:NSDefaultRunLoopMode beforeDate:[[NSRunLoop
currentRunLoop] limitDateForMode:NSDefaultRunLoopMode]];
Well, that's the most primitive loop. What you've essentially done is
replace the [NSDate distantFuture] timeout with one that matches when
your timer will fire (limitDateForMode: computes when the next timer
will fire). runMode:beforeDate: could be used in the same way, passing
what would be the fire date(s) of the timer instead of [NSDate
distantFuture] as the timeout date. The timer seems to be a mechanism
for polling the 'running' state, so you could just get to that more
directly via the beforeDate: parameter and skip the repeating timer.
One can look at that as "make sure I wake up at least every minute [or
other time period] to see if I should keep running". Actually using a
"real" source to poke the run loop into returning is the less-polling
way to do things.
Chris Kane
Cocoa Frameworks, Apple
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.