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 (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

Reply via email to