In my iOS app, I would like to wait for a condition to become true before updating the UI.
I am doing like this:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
while (!condition) NSLog("waiting for the condition");
dispatch_sync(dispatch_get_main_queue, ^{
//update the UI here
});
});
The code above works just fine but I would like to ask if using the while loop to do the waiting job is good or not, and if there is any better way.
Thanks!
---Update
The condition is actually a combination of 4 BOOL variables. Each variable associates with a request for content from the server. I'm using AFNetworking framework. In the completion block of each of the 4 requests, I will set the associated BOOL variable to YES.
So, the actual while loop is like this:
while (!([MyRequest request1].isFinished && [MyRequest request2].isFinished && [MyRequest request3].isFinished && [MyRequest request4].isFinished)) NSLog("waiting for the condition");
In the revised question, it sounds like you have four AFNetworking operations that you want to be dependent upon. That's far easier. You might just add a new operation, and make it dependent upon the other four operations:
NSOperation *operation = [NSBlockOperation blockOperationWithBlock:^{
[[NSOperationQueue mainQueue] addOperationWithBlock:^{
// update UI
}];
}];
[operation addDependency:requestOneOperation];
[operation addDependency:requestTwoOperation];
[operation addDependency:requestThreeOperation];
[operation addDependency:requestFourOperation];
[queue addOperation:operation];
The addDependency mechanism essentially does KVO of isFinished of each of those other four operations for you. It's one of the joys of using an NSOperation-based framework like AFNetworking. This sort of dependency is really easy to do.
Original answer:
If you had to do this, you might use a semaphore instead, e.g., you'd create a semaphore:
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
You'd have your async block wait for that:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_HIGH, 0), ^{
dispatch_semaphore_wait(semaphore);
dispatch_sync(dispatch_get_main_queue, ^{
//update the UI here
});
});
And when the condition is satisfied, the code that would have otherwise set this condition flag would, instead:
dispatch_semaphore_signal(semaphore);
Having said that, I'd rather not see a queue blocked (even a concurrent global queue) like this unless absolutely necessary. If that other code could issue the semaphore signal, I'm not sure why it couldn't just initiate the UI update itself. If I did use this semaphore technique, at the very least I'd have this waiting process taking place on a queue of my own creation, not a global queue.
Another approach which you can use in many situations, and which I'd probably prefer, is to employ key value observing:
For example, I could observe the changing of they someProperty property of an object called obj like so:
[obj addObserver:self forKeyPath:#"someProperty" options:NSKeyValueObservingOptionNew context:NULL];
I would then implement observeValueForKeyPath:
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context
{
if ([keyPath isEqualToString:#"someProperty"])
{
NSLog(#"update UI here");
}
}
Whenever the someProperty property of my obj object is updated, my observeValueForKeyPath method would be called.
FYI, I'd also make sure that before this object gets released, I'd remove the observer of obj:
[obj removeObserver:self forKeyPath:#"someProperty"];
Clearly, this assumes that someProperty is Key Value Coding Compliant. But if it is, this is a great technique.
While the general pattern here is correct (Apple refers to it as "call callback"), the while(!condition) bit is also known as a "spin lock", and is definitely not the best way to wait for a condition. Consider using NSTimer or NSRunLoop instead.
Earlier today I asked the following question: iOS block being stoped when view pushed
The operation I mentioned (OP1) is actually a "http get" to my server, using NSURLConnection.
After even more investigation I discovered that the block doesn't actually "die". What really happens is that the request is actually SENT (the server side logs it), even after the view is pushed (verified via [NSThread sleep:10]). The server responds but then NOTHING happens on the app side if the view2 has been pushed! almost as if the connection had lost its delegate! Another possibility im looking at is "the fact that NSURLConnection is on the rsMainLoop related?"
Can anyone help?
Pls don't forget that:
0. Everything works fine as long as the view2 is not pushed until operation completion.
1. The request is sent async
2. I set the delegate and it works as long as the view dont change
3. view1 starts the operation using the "singleton object reference" property "OP1Completed"
4. view2 checks the completion of OP1 via propertie on the "singleton object reference"
5. view2 gets the "result" by going to the "singleton.OP1Result" property
Edit 1:
Ok lets have some code. First here is the relevant code of my singleton (named "Interaction"):
-(void)loadAllContextsForUser:(NSString *)username{
userNameAux = username;
_loadingContextsCompleted = NO;
if (contextsLoaderQueue == NULL) {
contextsLoaderQueue = dispatch_queue_create("contextsLoaderQueue", NULL);
}
dispatch_async(contextsLoaderQueue, ^{
NSLog(#"Loading all contexts block started");
[self requestConnectivity];
dispatch_async(dispatch_get_main_queue(), ^{
[Util Get:[NSString stringWithFormat:#"%#/userContext?username=%#", Util.azureBaseUrl, [username stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding]]
successBlock:^(NSData *data, id jsonData){
NSLog(#"Loading all contexts block succeeded");
if([userNameAux isEqualToString:username]){
_allContextsForCurrentUser = [[NSSet alloc]initWithArray: jsonData];
}
} errorBlock:^(NSError *error){
NSLog(#"%#",error);
} completeBlock:^{
NSLog(#"load all contexts for user async block completed.");
_loadingContextsCompleted = YES;
[self releaseConnectivity];
}];
});
while (!_loadingContextsCompleted) {
NSLog(#"loading all contexts block waiting.");
[NSThread sleepForTimeInterval:.5];
}
});
NSLog(#"Load All Contexts Dispatched. It should start at any moment if it not already.");
}
And here is the class Util, which actually handles the request/response
-(id)initGet:(NSString *)resourceURL successBlock:(successBlock_t)successBlock errorBlock:(errorBlock_t)errorBlock completeBlock:(completeBlock_t)completeBlock;{
if(self=[super init]){
_data=[[NSMutableData alloc]init];
}
_successBlock = [successBlock copy];
_completeBlock = [completeBlock copy];
_errorBlock = [errorBlock copy];
NSURL *url = [NSURL URLWithString:resourceURL];
NSMutableURLRequest *request = [NSURLRequest requestWithURL:url];
[[NSURLConnection alloc] initWithRequest:request delegate:self startImmediately:YES];
//[_conn scheduleInRunLoop:[NSRunLoop mainRunLoop] forMode:NSDefaultRunLoopMode];
//[_conn start];
NSLog(#"Request Started.");
return self;
}
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response
{
[_data setLength:0];
}
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
{
[_data appendData:data];
}
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
{
id jsonObjects = [NSJSONSerialization JSONObjectWithData:_data options:NSJSONReadingMutableContainers error:nil];
id key = [[jsonObjects allKeys] objectAtIndex:0];
id jsonResult = [jsonObjects objectForKey:key];
_successBlock(_data, jsonResult);
_completeBlock();
}
- (void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
{
_errorBlock(error);
_completeBlock();
}
And finally here is the relevant part VC1 (pushing in VC2)
- (IBAction)loginClicked {
NSLog(#"login clicked. Preparing to exibit next view");
UIStoryboard *storyboard = [UIStoryboard storyboardWithName:#"MainStoryboard_iPhone" bundle:nil];
AuthenticationViewController *viewController = (AuthenticationViewController *)[storyboard instantiateViewControllerWithIdentifier:#"ContextSelectionView"];
NSLog(#"Preparation completed. pushing view now");
[self presentViewController:viewController animated:YES completion:nil];
}
You might be surprised, but there are a couple of solutions - some of which are very common and can be implemented very easily ;) Even though, this answer is ridiculous elaborate, the actual solution to your problem will not exceed a few lines of code. :)
You ran into a typical "async problem" - well, it's less than a problem, rather a typical programming task nowadays.
What you have is an asynchronous task, OP1. This will be started from within ViewController 1 (VC1), and at some indeterminate time later, it will eventually produce either a result or an error.
The eventual result of OP1 should be handled later in VC2.
There are a few approaches how a client can obtain the eventual result, for example: via KVO, delegate method, completion block, callback function, future or promise and per notification.
These approaches above have one property in common: the call-site gets notified by the asynchronous result provider (and not vice versa).
Polling for the result until it is available, is a bad approach. Likewse, hanging in a semaphore and blocking the current thread until the result is "signaled" is equally suboptimal.
You are probably familiar with completion blocks. A typical asynchronous method which notifies the call-site when the result is available looks like this:
typedef void (^completion_block_t)(id result);
- (void) doSomethingAsyncWithCompletion:(completion_block_t)completionHandler;
Note: the call-site provides the completion handler, while the async tasks calls the block when it is finished, and passes its result (or error) to the result parameter of the block. Unless otherwise stated, the execution context - that is the thread or dispatch queue or NSOperationQueue - of where the block will be executed is not known.
But when thinking about your problem, a simple async function and a completion handler doesn't yield a viable solution. You cannot pass that "method" easily from VC1 to VC2 and then later "attach" somehow a completion block in VC2.
Luckily, any asynchronous task can be encapsulated into an NSOperation. An NSOperation has a completion block as a property which can be set by the call-site or elsewhere. And an NSOperation object can be easily passed from VC1 to VC2. VC2 simply adds a completion block to the operation, and eventually gets notified when its finished and the result is available.
However, while this would be a viable solution for your problem - there are in fact a few issues with this approach - which I don't want to elaborate, but instead propose an even better one: "Promises".
A "Promise" represents the eventual result of an asynchronous task. That is, a promise will exist even though the result of the asynchronous task is not yet evaluated. A Promise is an ordinary object which you can send messages. Thus, Promises can be passed around much like NSOperations. A Promise is the return value of an asynchronous method/function:
-(Promise*) doSomethingAsync;
Don't mismatch a Promise with the asynchronous function/method/task/operation - the promise is just a representation of the eventual result of the task.
A Promise MUST be eventually resolved by the asynchronous task - that is, the task MUST send the promise a "fulfill" message along with the result value, or it MUST send the promise the "reject" message along with an error. The promise keeps a reference of that result value passed from the task.
A Promise can be resolved only once!
In order to obtain the eventual result a client can "register" a success handler and an error handler . The success handler will be called when the task fulfills the promise (that is, it was successful), and the error handler will be called when the task rejected the promise passing along the reason as an error object.
Assuming a particular implementation of a promise, resolving a promise may look like this:
- (Promise*) task {
Promise* promise = [Promise new];
dispatch_async(private_queue, ^{
...
if (success) {
[promise fulfillWithValue:result];
}
else {
NSError* error = ...;
[promise rejectWithReason:error];
}
});
return promise;
}
A client "registers" handlers for obtaining the eventual result as follows:
Promise* promise = [self fetchUsers];
promise.then( <success handler block>, <error handler block> );
The success handler and error handler block are declared as follows:
typedef id (^success_handler_block)(id result);
typedef id (^error_handler_block)(NSError* error);
In order to just "register" a success handler (for the case, the async tasks "returns" successfully) one would write:
promise.then(^id(id users) {
NSLog(#"Users:", users);
return nil;
}, nil);
If the task succeeds, the handler will be called - which prints the users to the console.
When the task fails, the success handler will not be called.
In order to just "register" an error handler (for the case, the async tasks fails) one would write:
promise.then(nil, ^id(NSError* error) {
NSLog(#"ERROR:", error);
return nil;
}, nil);
If the task succeeds, the error handler will not be called. Only if the task fails (or any children tasks), this error handler will be invoked.
When the result of the async task is eventually available, the code within the handlers will be executed "in some unspecified execution context". That means, it may execute on any thread. (Note: there are ways to specify the execution context, say the main thread).
A promise can register more than one handler pair. You can add as many handlers as you want, and where and when you want. Now, you should understand the connection with your actual problem:
You can start an asynchronous task in VC1, and get a promise. Then pass this promise to VC2. In VC2 you can add your handler, which will get invoked when the result is eventually available.
Don't worry when the result is actually already available when passing the promise to VC2, that is, when the promise has been resolved already. You can still add handlers and they get fired properly (immediately).
You can also "chain" multiple tasks - that is, invoke task2 once when task1 is finished. A "chain" or "continuation" of four async tasks looks as follows:
Promise* task4Promise =
[self task1]
.then(^id(id result1){
return [task2WithInput:result1];
}, nil)
.then(^id(id result2){
return [task3WithInput:result2];
}, nil)
.then(^id(id result3){
return [task4WithInput:result3];
}, nil);
task4Promise represents the eventual result of task4WithInput:.
One can also execute tasks in parallel, like taskB and taskC which will get started in parallel when taskA has been finished successfully:
Promise* root = [self taskA];
root.then(^id(id result){
return [self taskB];
}, nil);
root.then(^id(id result){
return [self taskC];
}, nil);
With this scheme, one can define an acyclic graph of tasks, where each is dependent on the successful execution of its successor ("parent"). "Errors" will be passed through to the root, and handled by the last error handler (if any).
There are a few implementations for Objective-C. I've written one myself: "RXPromise" (available on GitHub). One of the strongest feature is "Cancellation" - which is NOT a standard feature of promises, but implemented in RXPromise. With this, you can selectively cancel a tree of asynchronous tasks.
There is a lot more about promises. You may search the web, especially in the JavaScript community.
I'm not sure I understand the work flow that goes on in the first controller -- specifically, what the user does to initiate the download, and what else he does before the next controller gets presented (and when that controller gets instantiated). When I've made apps in the past that required doing downloads from multiple classes, I've created a download class that creates the NSURLConnection, and implements all the call backs. It has one delegate protocol method to send back the data (either raw data or error object) to its delegate.
I made a simple test case simulating what I think your work flow is, using two buttons. One instantiates a Downloader class instance, creates the next controller, sets it as the delegate of the downloader, and starts the download. The second button does the push to that second controller. This works, no matter when the push happens, but I don't know if it's relevant to your situation (I test using the Network Link Conditioner to simulate a slow connection).
The first Controller:
#import "ViewController.h"
#import "ReceivingViewController.h"
#import "Downloader.h"
#interface ViewController ()
#property (strong,nonatomic) ReceivingViewController *receiver;
#end
#implementation ViewController
-(IBAction)buttonClicked:(id)sender {
Downloader *loader = [Downloader new];
self.receiver = [self.storyboard instantiateViewControllerWithIdentifier:#"Receiver"];
loader.delegate = self.receiver;
[loader startLoad];
}
-(IBAction)goToReceiver:(id)sender {
[self.navigationController pushViewController:self.receiver animated:YES];
}
The Download class .h:
#protocol DownloadCompleted <NSObject>
-(void)downloadedFinished:(id) dataOrError;
#end
#interface Downloader : NSObject
#property (strong,nonatomic) NSMutableData *receivedData;
#property (weak,nonatomic) id <DownloadCompleted> delegate;
-(void)startLoad;
Downloader .m:
-(void)startLoad {
NSLog(#"start");
NSURLRequest *request = [NSURLRequest requestWithURL:[NSURL URLWithString:#"http://www.google.com"] cachePolicy:NSURLRequestReloadIgnoringLocalAndRemoteCacheData timeoutInterval:10];
NSURLConnection *connection = [NSURLConnection connectionWithRequest:request delegate:self];
if (connection) self.receivedData = [NSMutableData new];
}
-(void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
self.receivedData.length = 0;
}
-(void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data {
[self.receivedData appendData:data];
}
-(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error {
[self.delegate downloadedFinished:error];
}
-(void)connectionDidFinishLoading:(NSURLConnection *)connection {
[self.delegate downloadedFinished:self.receivedData];
}
-(void)dealloc {
NSLog(#"In Downloader dealloc. loader is: %#",self);
}
The second controller:
#interface ReceivingViewController ()
#property (strong,nonatomic) NSData *theData;
#end
#implementation ReceivingViewController
-(void)downloadedFinished:(id)dataOrError {
self.theData = (NSData *)dataOrError;
NSLog(#"%#",self.theData);
}
-(void)viewDidAppear:(BOOL)animated {
[super viewDidAppear:animated];
NSLog(#"%#",self.theData);
}
So, here is what I think will work for sure:
Pass the flag to the new controller. If the flag is unfinished, then start over loading in the new VC and make sure none of the data shows up until it is done loading.
I do think it is weird that the thread stops though, with the new VC being pushed, because when I dispatch asynchronous calls with AFNetworking, it does continue to load even after a new VC is pushed. Perhaps if you are using a different framework, you should use AFNetworking.
So, if your thread actually does continue after the new VC is pushed on (as I suspect it does - you just think it doesn't keep going because it crashes the code), then try the following:
a) pass flag, if operation finished, proceed normally
b) if not, don't load anything and invoke some kind of delegate method between the two that checks if the flag is set, and returns the data if so.
If you have questions on how to set up a delegate, just ask and I can fill in some details on that.
As already mentioned in a comment in you first question: you have probably two issues:
A design problem
A code issue, causing the block. (but without code this is difficult to figure out).
Lets propose a practical approach:
Say, our singleton is some "Loader" class which performs HTTP requests. Instead of polling a property which determines the state of the network request, you should return some object which you can ask for the state, or even better where VC2 can register a completion block which gets called when the request is finished.
An NSOperation could be "used" to represent the eventual result of the asynchronous network request. But this is a bit unwieldy - suppose we have a subclass RequestOperation:
RequestOperation* requestOp = [[Loader sharedLoader] fetchWithURL:url];
Now, "requestOp" represents your network request, including the eventual result.
You can obtain this operation in VC1.
You may not want to ask the shared loader about a particular operation, because it may stateless -- that is, it does not itself track the request operations. Consider, you want to use class Loader several times for starting network requests - possible in parallel. Then, which request do you mean when you ask one property of Loader which tells you something about the state of a request? (it won't work).
So, again back to a working approach and to VC1:
Suppose, in VC1 you obtained the RequestOperation object which is a subclass of NSOperation. Suppose, RequestOperation has a property responseBody - which is a NSData object representing the eventual response data of the request operation.
In order to obtain the eventual response body of the request, you cannot just ask the property: the connection could possibly still running - the you would get nil or garbage, or you might block the thread. The behavior is dependent on the implementation of RequestOperation.
The solution is as follows:
In VC2:
We assume, VC1 has "passed" the requestOp to VC2 (for example in prepareForSegue:sender:).
In order to retrieve the response body in an asynchronous correct manner, you need some extra steps:
Create a NSBlockOperation which executes a block which handles the response body, for example:
NSBlockOperation* handlerOp = [NSBlockOperation blockOperationWithBlock:^{
NSData* body = requestOp.responseBody;
dispatch_async(dispatch_get_main_queue(), ^{
self.model = body;
[self.tableView reloadData];
});
}];
Then, make the handlerOp dependent on the requestOp - that is, start executing handlerOp when requestOp finished:
[handlerOP addDependency:requestOp];
Add the handlerOp to a queue, in order to execute:
[[NSOperation mainQueue] addOperation:handlerOp];
This still requires you to think "asynchronously" - there is no way around this. The best is, to get used to the practical patterns and idioms.
An alternative approach is using RXPromise (from a third party library):
In VC1:
requestPromise = [Loader fetchWithURL:url];
Now, in VC2:
We assume, VC1 has "passed" the requestPromise to VC2 (for example in prepareForSegue:sender:).
For example in viewDidLoad:
requestPromise.thenOn(dispatch_get_main_queue(), ^id(id responseBody){
// executes on main thread!
self.model = responseBody;
[self.tableView reloadData];
return nil;
}, nil);
Bonus:
If required, you can cancel the network request at any time through sending cancel to the promise:
- (void)viewWillDisappear:(BOOL)animated {
[super viewWillDisappear:animated];
[self.requestPromise cancel];
self.requestPromise = nil;
}
I've figured it out. In my second view (where i w8 for the operation complete) I cannot w8 using ThreadSleep! I have to use [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
From a view controller, as a result of a button action, I need to create a custom object that manages a set of asynchronous remote service calls, and call the method of such object that fires those service calls. I need the view controller to wait for all the async networking operations to have finished in order to update its view. Since the networking operations are async, I don't know how I'd communicate from the custom object managing this tasks to the view controller when all operations are done.
Here is the code I currently have. The code snippet in the view controller is like this (result var is not currently used):
- (void)loadData
{
BOOL __block result = NO;
dispatch_queue_t queue = dispatch_queue_create(dataLoadQueue, NULL);
dispatch_async(queue,^{
Loader *loader = [[Loader alloc] init];
[loader loadData];
dispatch_async(dispatch_get_main_queue(), ^{
if (result) {
// Update view and notify success
}
else {
// Update view and notify error
}
});
});
dispatch_release(queue);
}
And this is the loader custom object side:
- (void)loadData
{
if ([Reachability checkNetStatus]) {
Service1 *service1 = [[Service1 alloc] init];
[service1 callAsyncService];
Service2 *service2 = [[Service2 alloc] init];
[service2 callAsyncService];
// More service calls
}
else {
// Notify network not reachable
}
}
Objects service1, service2... serviceN conform the NSURLConnectionDelegate and I notify they have finished in its connectionDidFinishLoading: by means of the NSNotificationCenter (loader object is listening for such notifications). Then, I don´t know what is the correct way of making loader wait for all the networking operations, and notify back the view controller.
Thanks in advance
There are probably lots of ways you could do this. First, I don't think there's any need to use GCD in the view controller -- loader is already doing things asynchronously, so the creation of loader is fast.
As for how Loader knows when all its network operations are done, you could just keep a list of strings in a mutable array, like "1 done", "2 done", etc. that would be the same as strings sent in the user info of the notifications called in connectionDidFinishLoading:. All the services could send the same notification, but with different user info. In the selector for the observer, remove the string identical to the one in the user info, and check if the array is empty -- when it is, all your services are done. At that point, I would use a delegate method to pass back the data to the view controller. Something like this in Loader:
- (void)viewDidLoad {
[super viewDidLoad];
self.doneStrings = [#[#"1 done", #"2 done", #"3 done", #"4 done"] mutableCopy];
[[NSNotificationCenter defaultCenter] addObserver:self selector:#selector(notificationReceived:) name:#"SeriveFinishedNotification" object:nil];
}
-(void)notificationReceived:(NSNotification *) aNote {
[self.doneStrings removeObjectIdenticalTo:[aNote.userInfo objectForKey:#"doneString"]];
if (self.doneStrings.count == 0)
[delegate doSomethingWithTheData: theData];
}
You would probably need to some other things like handle the case where some of the network operations fail.
If you want to wait until the async tasks were done, you can use a semaphore. See the example below, the logic is pretty simply. I think you can easily adapt to your case.
//create the semaphore
dispatch_semaphore_t semaphore = dispatch_semaphore_create(0);
[objectManager.HTTPClient deletePath:[address addressURL] parameters:nil success:^(AFHTTPRequestOperation *operation, id responseObject) {
//some code here executed in background
dispatch_semaphore_signal(semaphore); //sends a notification to release the semaphore
}failure:^(AFHTTPRequestOperation *operation, NSError *error) {
//some other code here also executed in background
dispatch_semaphore_signal(semaphore); //sends a notification to release the semaphore
}];
//holds the thread until the dispatch_semaphore_signal(semaphore) is send
while (dispatch_semaphore_wait(semaphore, DISPATCH_TIME_NOW))
{
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate dateWithTimeIntervalSinceNow:10]];
}
You haven't shared the details of how these asynchronous requests work, but another approach is to make these asynchronous requests NSOperation objects that you submit to a NSOperationQueue. (AFNetworking is an example of this sort of implementation.) When you do that, you can create yet another NSOperation to be triggered upon the completion of the network request operations, by make it dependent upon those network request operations. Thus it will only run when all of the network requests are done. Using an NSOperation-based solution enjoys other benefits, too (e.g. you can use setMaxConcurrentOperationCount to let you enjoy concurrency, but not run too many concurrent requests at any given time).
References
Ray Wenderlich's How To Use NSOperations and NSOperationQueues
Defining a Custom Operation Object in Apple's Concurrency Programming Guide
Sorry, it's a bit wordy, but I wanted to make sure I was clear! ;-)
I have an iOS app that uses FFMPEG for streaming RTSP. I've multi-threaded FFMPEG using NSOperationQueue such that most its work, other than painting the image to the screen, of course, happens in background threads.
Works great! ...except for the fact that threads the NSOperationQueue creates never die!
I init the Queue in the class' init method with:
self->opQ = [[NSOperationQueue alloc] init];
[self->opQ setMaxConcurrentOperationCount:1];
I add methods to the Queue using blocks:
[self->opQ addOperationWithBlock:^{
[self haveConnectedSuccessfullyOperation];
}];
Or
[self->opQ addOperationWithBlock:^{
if (SOME_CONDITION) {
[self performSelectorOnMainThread:#selector(DO_SOME_CRAP) withObject:nil waitUntilDone:NO];
}
}];
Later, when I need to tear down the RTSP stream, in addition to telling FFMPEG to shut down, I call:
[self->opQ cancelAllOperations];
Which does indeed stop the threads from doing any work , but never actually destroys them. Below, you'll see a screen shot of threads that are doing nothing at all. This is what my threads look like after starting/stoping FFMPEG several times.
I seem to remember reading in Apple's documentation that NSOperations and the threads they are run on are destroyed once they are done executing, unless otherwise referenced. This doesn't appear to be the case.
Do I just need to destroy the NSOperationQueue, then re-init it when I need to start up FFMPEG again (I just realized I haven't tried this)? Anyone know how I need to kill these extra threads?
THANKS!
I solved it by creating NSBlockOperations so that I could monitor the isCancelled state, while also making the new NSBlockOperations' content more intelligent, such that I simplified the routine that would add the operations to the queue.
... Plus, I made an NSOperationQueue n00b mistake: I was adding operations to the queue on a looping basis, which fired up to 30 times per second (matching the video's frame rate). Now, however, the operation is added to the queue only once and the looping behavior is contained within the operation instead of having the loop add the operation to the queue.
Previously, I had something like this (pseudo code, since I don't have the project with me):
NSTimer *frameRateTimeout = [NSTimer scheduledTimerWithTimeInterval:1/DESIRED_FRAMES_PER_SECOND target:self selector:#selector(ADD_OPERATION_TO_QUEUE_METHOD:) userInfo:nil repeats:YES];
-(void)ADD_OPERATION_TO_QUEUE_METHOD:(NSTimer *)timer {
[opQ addOperation:displayFrame];
}
Which worked well, as the OS would correctly manage the queue, but it was not very efficient, and kept those threads alive forever.
Now, it's more like:
-(id)init {
self = [super init];
if (self) {
// alloc/init operation queue
...
// alloc/init 'displayFrame'
displayFrame = [NSBlockOperation blockOperationWithBlock:^{
while (SOME_CONDITION && ![displayFrame isCancelled]) {
if (playVideo) {
// DO STUFF
[NSThread sleepForTimeInterval:FRAME_RATE];
}
else { // teardown stream
// DO STUFF
break;
}
}
}];
}
return self;
}
- (void)Some_method_called_after_getting_video_ready_to_play {
[opQ addOperation:displayFrame];
}
Thanks, Jacob Relkin, for responding to my post.
If anyone needs further clarification, let me know, and I'll post better code once I have the project in my hands again.
The problem is that I manage scrollView with lots of tiles in it.
Each visible tile display image loaded from URL or (after first URL load) cached file in background. Invisible tiles recycles (set new frame and redraw).
Image load depends on tile position.
With long range scroll there is multiple redraw called for each tile: each tile loads (and display) different image several times before display the correct one.
So problem is to cancel all previously added operations for tile before add new.
I subclass NSInvocationOperation just to contain context object to detect operation attached to and before add new operation I canceling all operation for same tile:
-(void)loadWithColler:(TileView *)coller {
if (queue == nil) {
queue = [NSOperationQueue new];
}
NSInvocationOperationWithContext *loadImageOp = [NSInvocationOperationWithContext alloc];
[loadImageOp initWithTarget:self selector:#selector(loadImage:) object:loadImageOp];
[loadImageOp setContext:coller];
[queue setSuspended:YES];
NSArray *opers = [queue operations];
for (NSInvocationOperationWithContext *nextOperation in opers) {
if ([nextOperation context] == coller) {
[nextOperation cancel];
}
}
[queue addOperation:loadImageOp];
[queue setSuspended:NO];
[loadImageOp release];
}
And in operation itself I check isCancelled:
-(void)loadImage:(NSInvocationOperationWithContext *)operation {
if (operation.isCancelled) return;
TileView *coller = [operation context];
/* TRY TO GET FILE FROM CACHE */
if (operation.isCancelled) return;
if (data) {
/* INIT WITH DATA IF LOADED */
} else {
/* LOAD FILE FROM URL AND CACHE IT */
}
if (operation.isCancelled) return;
NSInvocationOperation *setImageOp = [[NSInvocationOperation alloc] initWithTarget:coller selector:#selector(setImage:) object:cachedImage];
[[NSOperationQueue mainQueue] addOperation:setImageOp];
[setImageOp release];
}
But it is do nothing. Some times early returns works but tiles still load many images before the correct one.
So how could I success? And could this lots of unneeded operations cause delays on main thread when scrolling? (Because delays are exists and I do not know why...all load in background..)
Update:
With NSLog:
isCancelled while executing:
>
cancel loadImage method for:
>
So canceling work.
Now I save reference to last operation in TileView object and perform setImage operation only if invoked operation is equal to TileView operation.
Doesn't make any difference...
Looks like there IS number of operations to load different images to one tile invoked one after another.
Any another suggestions?
For clearance:
There is singleton DataLoader (all code from it). And all tiles has call to it in drowRect:
[[DataLoader sharedDataLoader] loadWithColler:self];
Update:
NSInvocationOperation subclass:
#interface NSInvocationOperationWithContext : NSInvocationOperation {
id context;
}
#property (nonatomic,retain,readwrite) id context;
#end
#implementation NSInvocationOperationWithContext
#synthesize context;
- (void)dealloc
{
[context release];
[super dealloc];
}
#end
Thanks a lot for any help!
SOLUTION:
From answer below: need to subclass from NSOperation
As I subclass NSOperation and put all loadImage: code into it "main" method (just move all code here and nothing else) and all work just perfect!
As about scroll delaying: it occurs cause loading images to UIImageView (it takes long time because of decompress and rasterize (as I understood).
So better way is to use CATiledLayer. It loads data in background and do it much faster.
The delays on main thread is due to a the mode of the runloop while you scroll. I suggest you to watch the WWDC2011 networking app sessions. I don't know if it is fine to subclass an NSInvocationOperation that is a concrete subclass of NSOperation. I will subclass NSOperation instead. For my experience if you like to avoid sluggish scrolling, you should create NSOperation subclasses that load their main on a specific thread for networking operation (you must create it). There is a wonderful sample code from apple https://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html
The way that NSOperationQueue works with respect to "setSuspended" is that it won't start to run newly added NSOperations added to it after that point, and won't start to run any that are currently in it that haven't started running yet. Are you sure your operations you're trying to cancel haven't already started yet?
Also - does your NSOperation subclass correctly deal with Key Value Observing? Concurrent Queue subclassed NSOperations have to call willChangeValueForKey and didChangeValueForKey for some properties here - but doesn't look like that's the issue as your queue doesn't set isConcurrent. Just FYI if you go that route.