How do I wait until an NSOperationQueue has finished in a Unit Test?

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 le开发者_开发百科ss 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?

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.

I'd say that waitUntilAllOperationsAreFinished should work as expected on 10.6, no matter from what thread it's called. Since operation queues in 10.6 no longer use the run loop, there is no point in not blocking and having the loop run. Did you try to just call waitUntilAllOperationsAreFinished=

I agree with Max: -waitUntilAllOperationsAreFinished should work. Is your queue -suspended ?

IMHO you need to consider the possibility that waitUntilAllOperationsAreFinished may hang if one (or all) of its operations are progressing using main app thread as a carrier. Example: your nsoperation is not concurrent and uses glkview auto-update loop for animation and updating own state and your operation is only done (and operation is marked finished) only if main thread has a chance to work. But it can't as it is blocked in waiting for finishing these operations.