Yes, I know. There are a lot of questions and answers about the NSOperation
world but I'm still having some doubts. Il' try to explain my doubts with a two parts question. They are related each other.
In the SO post nsoperationqueue-and-concurrent-vs-non-concurrent, Darren wrote that
A "concurrent" operation is concurrent on its own; it doesn't need NSOperationQueue to create a thread for it.
But searching a little bit, I've found that a NSOperation
, even if it is declared concurrent (by means of overriding the isConcurrent
method such as it returns YES
), can be added to NSOperationQueue
. What does this mean? If I add a concurrent NSOperation
to a queue, what is going on under the hood? On the contrary, what happens if I use a concurrent operation as is (without adding it to a queue)?
The note taken from Apple doc is clear:
...operation queues ignore the value returned by isConcurrent and always call the start method of your operation from a separate thread. ...In general, if you are always using operations with an operation queue, there is no reason to make them concurrent.
Then, I'm really interested about using async pattern in NSOperation
. I've found a good tutorial by Dave Dribin (concurrent operations). I got the overall meaning of his post.
You cannot use an async pattern (e.g. using an async NSURLConnection
request) since delegates could not be called. When the main
finishes the operation is removed. The solution is to override the start
method to control the operation lifecycle...And dealing with run loops could be a pain.
Now, trying to understand his post, my doubt is about the need to run the start
method in the main thread.
- (void)start
{
if (![NSThread isMainThread])
{
[self performSelectorOnMainThread:@selector(start) withObject:nil waitUntilDone:NO];
return;
}
// other code here...
}
When dealing with asynchronous APIs, we can begin the asynchronous call on the main thread in start and keep the operation running until it finishes.
Could you explain me why?
Thank you in advance.