NSOperation waitUntilFinished waits a long time - ios

Question

I am using an NSOperation subclass (called PointsOperation) to do some calculations in the background in my app. Due to user behaviour, these calculations might need to be canceled, and new calculations started. In that case, I will create a new PointsOperation instance, and add it to the same NSOperationQueue as the first one. As the first thing in the main method of the PointsOperation, it will check whether another operation is already running, and cancel it.
Because the operations are using some shared caches, they cannot be (and don't need to be) running in parallel. Therefore, the second operation will wait until the first one has finished. The resulting code for the main method looks something like this:
static NSOperation *currentOperation = nil;
- (void) main
{
// setting up autorelease pool, catching exceptions, etc
#synchronized(lock) {
if (currentOperation != nil) {
[currentOperation cancel];
[currentOperation waitUntilFinished];
}
currentOperation = self;
}
while (!calculationsFinished && ![self isCancelled]) {
// do calculations
}
currentOperation = nil;
// releasing autorelease pool, etc
}
This all works fine, the first operation gets cancelled, and the second waits for it to finish, and then starts calculating.
The problem is: it takes 3-10 seconds between the first operation ending the main method, and the second one to come out of the waitUntilFinished.
Does anybody have seen this before and knows what to do about that?
I have also tried, instead of the waitUntilFinished, to make the second operation dependent on the first, with "addDependency:" (in the init method, rather than the main). That also works, but has the same problem: the start of the second operation is a number of seconds behind the finish of the first method.

Answer 1

Despite of its name, the cancel method does not magically cancel the operation.
Canceling an operation does not immediately force it to stop what it
is doing. Although respecting the value returned by the isCancelled is
expected of all operations, your code must explicitly check the value
returned by this method and abort as needed.
http://developer.apple.com/library/mac/documentation/Cocoa/Reference/NSOperation_class/Reference/Reference.html
If you did not write your code to check isCancelled property, so the operation's thread will run to the end no matter you cancel it or not.

Answer 2

I tried to reproduce the issue here but my code just work fine with no such delay. This is my code:
#interface PointsOperation : NSOperation {
#private
bool calculationsFinished;
}
#property (nonatomic, assign) int tag;
#end
#implementation PointsOperation
#synthesize tag;
static NSOperation *currentOperation = nil;
static NSString* lock = #"LOCK";
- (void) main
{
NSLog(#"Before autoreleasepool with tag: %d", tag);
#autoreleasepool {
NSLog(#"Before lock");
// setting up autorelease pool, catching exceptions, etc
#synchronized(lock) {
if (currentOperation != nil) {
NSLog(#"Before cancel");
[currentOperation cancel];
NSLog(#"Before waitUntilFinished");
NSDate* beforeWait = [NSDate date];
[currentOperation waitUntilFinished];
NSLog(#"After waitUntilFinished took %f seconds", [[NSDate date] timeIntervalSinceDate:beforeWait]);
}
currentOperation = self;
}
NSLog(#"Before while loop");
int i = 0;
while (!calculationsFinished && ![self isCancelled]) {
// do calculations
[NSThread sleepForTimeInterval:1];
NSLog(#"Inside while loop = %d", i);
calculationsFinished = (++i > 10);
}
NSLog(#"After while loop: i = %d", i);
currentOperation = nil;
// releasing autorelease pool, etc
}
NSLog(#"%#", #"End of method");
}
#end
And here's how I use it:
NSOperationQueue* q = [[NSOperationQueue alloc] init];
q.maxConcurrentOperationCount = 4;
for (int i = 0; i < 10; i++) {
[q addOperation:[PointsOperation new]];
}
The result of time took by waitUntilFinished came in two categories:
After waitUntilFinished took 1.002624 seconds
and
After waitUntilFinished took 0.000749 seconds
which depends on the timing of the call I think.
Maybe you should provide more of your code if possible, as problem might be somewhere else in your code.