On Mar 20, 2009, at 12:22 PM, Robbie Hanson wrote:
How can I know if a fired timer has already been "invalidated" using setFireDate? Consider the following pseudo-code:- (void)dequeueNextOperation { // IF there is another operation in the queue // Dequeue and start opertation... // Start timeout timer for operation// Instead of creating a new timer for every operation, we'd like to simply recycle the same one [timer setFireDate:[NSDate dateWithTimeIntervalSinceNow:op- >timeout]];} // Called when the operation has completed - (void)operationComplete { // "invalidate" timer// We have learned that this will not always prevent the doTimeout: method from being called[timer setFireDate:[NSDate distantFuture]]; // Notify delegate of completed op[self performSelector:@selector(dequeueNextOperation) afterDelay: 0.0];} - (void)doTimeout:(NSTimer *)aTimer { // Is there anyway to tell if this timer has already // been "invalidated" in the operationComplete method? }Perhaps there is something clever I can do with the timer's userInfo variable or something?
Are you modifying the NSTimer from a separate thread? NSTimer/ CFRunLoopTimer is only marginally thread-safe. Specifically, calling setFireDate from another thread may do nothing because the runloop on which the timer is installed may be already blocked (and will not process the change). Instead, you should probably use non-repeating timers- one for each operation on the thread in which it runs.
Even if you not explicitly using threads here, you should likely go with creating individual one-time-firing NSTimers.
Cheers, M _______________________________________________ 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
