I'm fairly new to Objective-C and I can't figure out how to wait in a non-blocking manner. I have an object that is being populated asynchronously and I need to wait on it before I can proceed in another method. Right now I am using the sleep function, but this blocks the whole app and myObject never gets loaded.
while (!myObject)
{
sleep(1);
}
return myObject;
EDIT: This code snippet is from a method that may be called before myObject has been loaded. In this case I actually do want to block in this method, but my code blocks everything including myObject from being loaded.
This little peach worked for me (in-order to delay for 20 seconds)....
CFRunLoopRunInMode(kCFRunLoopDefaultMode, 20.0, false);
If you can, give the class a myObjectLoaded: method to be called when the object in question is loaded. Otherwise, the the most idiomatic equivalent of what you wrote above is to create a timer that keeps checking for myObject and does something once it finds it.
If you really needed to do it in the middle of a method for some reason, you'd have to create a loop that keeps running the runloop. It's the lack of a runloop that causes your app to block.
NSNotification should solve the problem.
http://developer.apple.com/documentation/Cocoa/Conceptual/Notifications/Introduction/introNotifications.html
Instead of waiting on on object, have this object register for notifications coming from your other object (say Publisher) which populates the data asynchronously. One this Publisher object finishes, have it post an NSNotification, which will then be automatically picked up by your waiting object. This would eliminate waiting too.
Sounds like you're looking for the observer pattern. Apple calls it "notification".
Assuming you have some background NSThread performing this population operation, you might like The NSObject method performSelector:onThread:withObject:waitUntilDone
That's because you are stopping the main thread waiting for your object to be loaded. Don't do that, because the main thread is the thread that drives the UI, and waits for user input. If you block the main thread you block the application user interface.
If you want the main thread to do something when the object is loaded, then create a method myObjectLoaded: and call from your loading threads:
[myObjectController performSelectorOnMainThread:#selector(myObjectLoaded:)
withObject:myObject
waitUntilDone:NO];
where myObjectController can be any object even myObject itself.
Related
I'm a windows developer and I'm having a hard time understanding the right way to run code in the
NSApplication's main thread.
Most of my code is running in a cvdisplaylink thread (it's an opengl app)
THe problem is that I can't call things like NSOpenPanel from it - it crashes the app and warns about only running stuff like this from the main thread.
It's fine, but the main thread is completely opaque as far as I understand, and I can only make it do things with events. The NSApp sendAction method sounded promising - because I could explicitly specify which method to call. But it didn't 'send' any thing, it just called this method directly from the same thread.
Am I understanding this right? Do I have to push some sort of a custom event (perhaps NSEventTypeApplicationDefined) to the main thread queue for this to work properly?
And if so, how to I respond to custom events like that?
Like this:
dispatch_async(dispatch_get_main_queue(), ^{
// do whatever
});
If what you want to do is to call a method of an Obj C object, the old school Cocoa way (which still works) is to use performSelectorOnMainThread:withObject:waitUntilDone:
E.g. to hide a window by calling its "orderOut:" method you would do this.
[theWindow performSelectorOnMainThread:#selector(orderOut:)
withObject:nil
waitUntilDone:NO];
I have a worker thread that I keep alive through a loop that's controlled by a flag. I need the thread to stay alive for the length of my application as it opens a permanent connection to a remote server.
I fire up that thread and call several methods on it with:
[worker performSelector:#selector(getBusy) onThread:worker withObject:nil waitUntilDone:NO];
This seems to work fine and the method is called. At some point in getBusy I try to call a method in the main thread with:
[delegate performSelectorOnMainThread:#selector(gotBusy) withObject:nil waitUntilDone:NO
where delegate is a reference to the class that starts the separate thread.
The problem is that gotBusy never gets called on the main thread. I've peppered it with NSLog() statements and I can't see them printed on the console.
What should I be looking for to debug this?
First, make sure delegate is not nil. Secondly, make sure your main event loop is not blocked and not running in a modal mode.
Is it possible that you never assigned delegate, so you're calling performSelectorOnMainThread on a nil object? You could try setting waitUntilDone to YES so your worker thread will block and let the delegate do its work.
I am new to programming. I am porting cpp (WIN32) to cocoa framework. I have a method called start(process) from where 2 methods gets called. I want to do the operation in it parallely.I want to do InterThread communication.
This can be done by performSelectorOnMainThread:withObject:waitUntilDone.
Here I need to call the 2nd thread first and the 1st thread is called second.The 2nd thread waits for the 1st thread's signal.(eg:1st thread does addition of two no's and 2nd thread does the display and some other operations)
[receiverobj performSelectorOnMainThread:withObject:waitUntilDone]
is the syntax for doing it.But both of them are instance methods of the same class.And the 1st threads return type is a void value and the 2nd threads return value is uint8_t. How to receive the signal from the 1st thread onto the second thread which has begun its execution just before the 1st Thread.
The first thing about Cocoa is that all display code should run on the main thread. So if you are asking how to let the main thread know it needs to do some display work, performSelectorOnMainThread:waitUntilDone: is the right answer. This method works by putting an artificial "event" in the main thread's run loop (the loop that processes events from the UI and timers etc). The receiver will invoke the method exactly as if you had called it directly but it will happen on the main thread.
If you want to signal another thread that the display work has finished, you can do it synchronously like this:
[receiver performSelectorOnMainThread: #selector(mySelector) withObject: nil waitUntilDone: YES];
The calling thread will then pause until the method has finished.
If you just want to fire and forget it's
[receiver performSelectorOnMainThread: #selector(mySelector) withObject: nil waitUntilDone: NO];
The pattern is generalisable to any thread with the method performSelectorOnThread:withObject:waitUntilDone:. However, if you do this, you must make sure the target thread is executing a run loop.
I have a window that displays some data in an NSTableView. This data is loaded in the background. The data-loading-thread is started in the windowDidLoad: method. If the window is closed before loading has finished, the background thread should be cancelled. I do this by signalling the thread in the windowWillClose: delegate method and waiting for the background thread to finish.
Now this all works perfectly. But I have one problem: How can I update the data in the table view? I have tried calling reloadData via performSelectorOnMainThread: but this leads to a race condition: The reloadData call is sometimes queued on the main thread after the window close command, and will execute after the window has closed, and everything goes up in flames.
What's the best way to control and communicate with a background thread?
Well, you know, this is exactly what makes the use of threading complex: you always face synchronization issues.
What I suggest is, instead of calling [tableView reloadData] from your thread, simply signal your controller (by calling a method controllerShouldReloadTable) and let your controller do the check if windowWillClose has been called or not. There might be a chance that your controller has been also released by the time controllerShouldReloadTable, and to fix this you will definitely need to retain the controller from the secondary thread.
On a side note, I would cancel the thread in viewDidUnload (for symmetry).
Most important: I would use asynchronous calls and a delegate class so that the whole multithreading issue is solved at its root.
EDIT: Sending asynchronously a request will not block the sending thread waiting for the response. Instead, asynchronous send (for NSURLConnection is called start) immediately returns (so, no blocking) and when the response is received, a delegate method will be called (i.e., connectionDidFinishLoading:) so that you can updated the model and the UI. Take a look at NSURLConnection docs, but as usual, I strongly suggest using [ASIHTTPRequest][2], which has many advantages.
following is .m code:
#import "ThreadLabAppDelegate.h"
#interface ThreadLabAppDelegate()
- (void)processStart;
- (void)processCompleted;
#end
#implementation ThreadLabAppDelegate
#synthesize isProcessStarted;
- (void)awakeFromNib {
//Set levelindicator's maximum value
[levelIndicator setMaxValue:1000];
}
- (void)dealloc {
//Never called while debugging ????
[super dealloc];
}
- (IBAction)startProcess:(id)sender {
//Set process flag to true
self.isProcessStarted=YES;
//Start Animation
[spinIndicator startAnimation:nil];
//perform selector in background thread
[self performSelectorInBackground:#selector(processStart) withObject:nil];
}
- (IBAction)stopProcess:(id)sender {
//Stop Animation
[spinIndicator stopAnimation:nil];
//set process flag to false
self.isProcessStarted=NO;
}
- (void)processStart {
int counter = 0;
while (counter != 1000) {
NSLog(#"Counter : %d",counter);
//Sleep background thread to reduce CPU usage
[NSThread sleepForTimeInterval:0.01];
//set the level indicator value to showing progress
[levelIndicator setIntValue:counter];
//increment counter
counter++;
}
//Notify main thread for process completed
[self performSelectorOnMainThread:#selector(processCompleted) withObject:nil waitUntilDone:NO];
}
- (void)processCompleted {
//Stop Animation
[spinIndicator stopAnimation:nil];
//set process flag to false
self.isProcessStarted=NO;
}
#end
I need to clear following things as per the above code.
How to interrupt/cancel processStart while loop from UI control?
I also need to show the counter value in main UI, which i suppose to do with performSelectorOnMainThread and passing argument. Just want to know, is there anyother way to do that?
When my app started it is showing 1 thread in Activity Monitor, but when i started the processStart() in background thread its creating two new thread,which makes the total 3 thread until or unless loop get finished.After completing the loop i can see 2 threads.
So, my understanding is that, 2 thread created when i called performSelectorInBackground, but what about the thrid thread, from where it got created?
What if thread counts get increases on every call of selector.How to control that or my implementation is bad for such kind of requirements?
Thanks
how to update UI controls in cocoa application from background thread
Simple: Don't.
How to interrupt/cancel processStart while loop from UI control?
Outside of processStart, set a flag variable. Inside of processStart, check that flag and exit the loop if it is set.
Don't try to “kill” a thread from another thread. It's always a bad idea. Tell the thread it's time to stop by setting the flag, and have the thread check that flag and stop at an appropriate time.
I also need to show the counter value in main UI, which i suppose to do with performSelectorOnMainThread and passing argument. Just want to know, is there anyother way to do that?
Yes.
When my app started it is showing 1 thread in Activity Monitor, but when i started the processStart() in background thread its creating two new thread,which makes the total 3 thread until or unless loop get finished.After completing the loop i can see 2 threads. So, my understanding is that, 2 thread created when i called performSelectorInBackground, but what about the thrid thread, from where it got created?
Profile your app using Instruments or Shark and look. It's probably the heartbeat thread for the progress indicator.
What if thread counts get increases on every call of selector.How to control that or my implementation is bad for such kind of requirements?
Every performSelectorInBackground:withObject: message starts a thread. If your thread count isn't going down, it's because your thread method didn't exit. If your thread count is too high, it's (probably) because you started too many threads.
There is a much better way to do this.
First, the general rule in Cocoa is never sleep. Think of this as special ultra-caffeinated Cocoa. For anything you might sleep for in another framework, there is almost always a better, usually easier, way in Cocoa.
With that in mind, look at processStart. All it does is do something every centisecond. How best to do that?
Cocoa has a class for this specific purpose: NSTimer. Create a timer that sends yourself a message at the desired interval, and respond to that message by updating the progress bar—that is, your timer callback method should essentially just be the loop body from processStart, without the loop.
By the way, 100 updates per second is overkill. First off, the user does not care that you have made 1/5th of a pixel's worth of progress since the last time you updated the bar. Second, the screen only updates about 60 times per second anyway, so updating anything visible faster than that is pointless.
- (void)dealloc {
//Never called while debugging ????
[super dealloc];
}
Assuming you put your app delegate in the MainMenu nib, the application object owns it because of that—but it doesn't know that, because it only knows about the app delegate as its delegate, which is a non-owning relationship. (And even if it were an owning relationship, that would just be two ownerships, of which the app would release one, which wouldn't help.)
However, the lifetime of the app delegate doesn't really matter. Its purpose as the delegate of the application means that it needs to last about as long as the application does, but when the application goes away, the process is exiting, which means the delegate will be deallocated as well, as part of the reclamation of the process's memory space. That's why dealloc isn't called—the whole process space goes away at once, instead of objects being deallocated one at a time.
So, in principle, yeah, the app delegate not getting explicitly cleaned up is kind of dodgy. In practice, don't put any temporary-files clean-up in its dealloc (use applicationWillTerminate: instead) and you'll be fine.
I typically work around the problem by putting all my real work in one or more other objects which the app delegate owns. The app delegate creates these other controllers in applicationWillFinishLaunching: and releases them in applicationWillTerminate:, so those objects do get dealloc messages. Problem solved.