Re: NSTimer & Runloop questions
Re: NSTimer & Runloop questions
- Subject: Re: NSTimer & Runloop questions
- From: Robbie Hanson <email@hidden>
- Date: Fri, 20 Mar 2009 13:41:18 -0500
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
All of the methods are run in the same thread. The "operations" are
asynchronous, and on the same thread/runloop.
Even if you not explicitly using threads here, you should likely go
with creating individual one-time-firing NSTimers.
I was worried this might be the answer...
I'm still a bit curious about the code I posted above. Is there any
way that the "dequeueNextOperation" method, which gets scheduled in
the "operationComplete" method, will run *before* the "doTimeout"
method? In other words, is there any possibility of this series of
events happening:
- dequeueNextOperation (starts async operation1, and sets fire date of
timer)
- operationComplete (sets fire date of timer to distant future, queues
call to dequeueNextOperation)
- dequeueNextOperation (starts async operation2, and sets fire date of
timer)
- doTimeout (called for operation1)
If this is at all possible (in any way, shape or form)?
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden