Question

The Problem

• I have an NSOperationQueue called logEntryGeneratorQueue
• I want to wait until all operations on the queue have completed

If I use:

[logEntryGeneratorQueue waitUntilAllOperationsAreFinished];

it works fine if the thread adding to the queue is in the background itself.

However, if I’m running this code via a unit test, it’ll be running on the main thread. So I
came up with this “solution”, which I really don’t like:

if ([NSThread isMainThread]) {
    while ([[logEntryGeneratorQueue operations] count] > 0) {
        [[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
    }
} else {
    [logEntryGeneratorQueue waitUntilAllOperationsAreFinished];
}

This was always less than ideal, but has always worked fine on 10.5. However, now I’ve upgraded my project to using the 10.6 SDK, and this breaks.

On one test, it actually quit the test before it completed. I’ve no idea why – I assume it’s something to do with the way NSOperationQueues work differently in 10.6 – they now use GCD.

What I’ve Tried

I’ve tried replacing the runUntilDate with sleep, which, as I thought, means every test pauses forever when it gets here.

My Question

Is there a better way to wait for an NSOperationQueue to finish on a main thread? If not, how can I get this code working under 10.6?

Answer 1

The Solution

I realised that my code was in an eternal loop because I was calling mergeChangesFromContextDidSaveNotification on the main thread whilst also waiting for the queue to finish on the main thread. And since the merge changes was called after waitUntilAllOperationsAreFinished, it never got executed.

I think the answer is to change where I run NSOperationQueues from. I shouldn’t run an NSOperationQueue that deals with core data stuff on the main thread. And I shouldn’t really be running this intensive stuff on the main thread for performance reasons anyway I guess.