What does isConcurrent mean for NSOperation running from NSOperationQueue?

Question

Because NSOperationQueue always run tasks on a new thread, I'm confused about the role of isConcurrent when NSOperation runs from NSOperationQueue.

If i have two subclasses of NSOperation, both running an async processes, both are launched from NSOperationQueue and in both I override isCancelled, isExecuting, isFinished and isReady. What will be the difference if at one I override isConcurrent to always return YES and the other always to return NO.

Who actually calls isConcurrent? How the logic change if it is NO or YES.

Answer 1

It's a legacy method, used before OS X v10.6 and before iOS 4, i.e. before the introduction of GCD for NSOperationQueue dispatch.

From the doc

Operation queues usually provide the threads used to run their operations. In OS X v10.6 and later, operation queues use the libdispatch library (also known as Grand Central Dispatch) to initiate the execution of their operations. As a result, operations are always executed on a separate thread, regardless of whether they are designated as concurrent or non-concurrent operations. In OS X v10.5, however, operations are executed on separate threads only if their isConcurrent method returns NO. If that method returns YES, the operation object is expected to create its own thread (or start some asynchronous operation); the queue does not provide a thread for it.

If you're running OS X >= 10.6 or iOS >= 4, you can safely ignore it.

As a confirmation of this fact, from the doc of isConcurrent

In OS X v10.6 and later, operation queues ignore the value returned by this method and always start operations on a separate thread.