I've been using -performSelectorInBackground in many of my apps, sort of oblivious to -detachNewThreadSelector. Now I am wondering what the differences are between the two. Are they pretty much interchangeable, or are there differences and places where one is superior to the other? Thanks!
They're identical. See documentation.
performSelectorInBackground:withObject:
The effect of calling this method is the same as if you called the detachNewThreadSelector:toTarget:withObject: method of NSThread with the current object, selector, and parameter object as parameters.
As Michael says, they are identical. I think, to use a thread by performSelectorInBackground:withObject: is easier way rather than NSThread.
However, NSThread can control its priority, stacksize, etc. If you'd like to customize the behavior, I recommend NSThread instead of performSelectorInBackground:withObject:.
Corey, if you're running on a new thread and you're using [object autorelease], you'll need to create your own autorelease pool. Fairly simple to do:
- (void)uploadDataOnThread
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// do something here...
[pool release];
}
Interesting you guys can't point out any differences between them-
I'll tell you this much. We have an iphone app that was locking up while we displayed the "internet activity" disclosure icon in the top bar and a window that said "Sending..." while we sent an audio file up to a server and performSelectorInBackground: was NOT working. When we swapped out performSelectorInBackground with detachNewThreadSelector, it worked fine but now it complains that no autoreleased objects running in that thread are subject to being released by the pool.. maybe this is because the pool is in the main thread?
Related
I am just trying to understand this: multithread is a way of firing a method in another thread, so it will not hang the main thread (when something heavy must be done). But I have seen stuff like this:
this goes on the main code:
[NSThread detachNewThreadSelector:#selector(createNewThread) toTarget:self withObject:nil];
and here goes the thread
-(void) createNewThread {
NSAutoreleasePool* p = [[NSAutoreleasePool alloc] init];
[self performSelectorOnMainThread:#selector(doSomeStuff) withObject:nil waitUntilDone:YES];
[p release];
}
My problem with this is: if the thread is intended to relieve the main thread from doing something, why is doSomeStuff being called using performSelectorOnMainThread? Isn't that insane? I mean, you fire a second thread just to run something on the main thread, a thread that in fact you shouldn't be using.
I have seen a lot of code on the web write this way.
I know that probably it is done that way because it is doing something that is not thread safe, but is doing this really useful? To me sounds that it is totally useless and it would be better to do something like
[self performSelector:#selector(doSomeStuff) withObject:nil afterDelay:0.01];
what do you guys think?
thanks in advance.
performSelectorOnMainThread:withObject:waitUntilDone: puts the call on a queue to perform on the next iteration of the run loop. performSelector:withObject:afterDelay: sets up a timer to perform the action. However, creating a new thread to call performSelectorOnMainThread makes no sense because it puts the call on the queue even if it is already on the main thread.
If that's the entire body of the createNewThread method then it makes no sense. But if other stuff actually happens in createNewThread then there might be a good reason. The most common scenario for having a background thread use performSelectorOnMainThread: is if the UI needs to update as a result of the background activity. Like if you're processing a large data set and you want to show the user how much progress has been made so far. UIKit is not thread-safe so you can't update the UI from the background thread. But you might do something like, have the background doing a lot of work in a loop, and at every pass through the loop (or every 5, or whatever) call back to the main thread to update the UI. This makes the code switch back to the main loop just long enough to update the UI before returning to the background for the heavy duty work.
I am a seemingly straightforward question that I can't seem to find an answer to (and it is hindering my app).
I have a background thread running a paricular method:
-(void)processImage:(UIImage *)image {
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
//Process image here in the background here
[pool drain];
}
This much works great, but my question comes when I want to call another method from inside the already-background method. Does this call stay in the background? Do I need to add NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; and [pool drain]; to the new method to make it run in the background as well?
Any advice would be very helpful. I am a bit confused about this.
Many thanks,
Brett
It WILL stay in the background, on the same thread it was called from.
Some threading notes to consider with this:
It may not be obvious, but if you call a timer from the background thread, and the thread exits before the timer is supposed to go off, the timer will NOT be called. Thus it is recommended you setup timers from the main thread
You dont need another autorelease pool unless you spawn another thread.
Any UI updates should be done on the main thread
You don't need to add yet another autorelease pool, the one you already have is enough. And yes, all calls that you make that originate from that thread stay in that thread and thus also run "in the background". Exception would be the use of "performSelectorOnMainThread:", which of course makes the given selector to be performed on the main thread :-) If you want to call GUI methods (like setting the image on an UIImageView) you should make sure to do so on the main thread. See the docs for "performSelectorOnMainThread:waitUntilDone:" (sorry for not giving you you the links, am typing this on my iPad).
i didn't really know how to title this question, but here's a thing that really kills me:
In my app i have a UITableView, UISegmentedControl and UINavigationBar. Once UISegmentedControl gets one of its segments selected i want to show a UIActivityIndicatorView on the UINavigationBar and then parse an xml file and present the results in a table.
Everything works almost as i want it to, except one thing, the activity indicator view gets added to the uinavigationbar after the parser finishes, even though the method showLoading that adds UIIndicatorView to UINavigationBar gets before parser is initialised.
Can anyone explain it? is there something i might be missing? maybe the ui needs to get redrawn?
thanks
peter
It looks that you parse your xml in main thread and so it becomes blocked for UI changes. Try to move xml parsing to separate thread (e.g. by calling your parsing method via -performSelectorInBackground:)
Edit: Actually you're (almost certainly) using autorelease implicitly in your application - as many standard functions return autoreleased objects. When you're running your functions on separate thread you need to create NSAutoreleasePool object there to handle autoreleased objects and avoid memory leaks (see Autorelease Pools in docs). So your parseXML function must look like:
- (void)parseXML{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
... //xml parsing routines etc
[pool release];
}
I'm new to Objective C, and Mac development... It appears that I can use the Posix threads API in my app.. Is this the recommended way? Or is their some Apple API I should be using for mutexes, condition variables and threads instead?
I should add that I'm developing for the iPhone.
I'd like to add exactly what I'm trying to do. Basically, CoreLocation is asynchronous... You tell it to start updating you, and then it just calls an update method on you periodically...
The problem I have is that I need another thread to block until an update occurs... How can I make the main application thread block until at least one CoreLocation update occurs? Is their an NSConditionVariable? :)
I'd suggest an even easier way to get stuck into threads is to use the following call:
[self performSelectorInBackground:(#selector(myMethod)) withObject:nil];
This will automatically create a new background thread for you to run in. Incidentally make sure you do the following inside your background method:
-(void) myMethod {
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
// code you want to run in background thread;
[pool drain];
}
This is necessary because there isn't a default autorelease pool set up for any threads except the main one.
Finally, talking about blocking the main thread, you could use the following from your background thread to do this:
[self performSelectorOnMainThread:(#selector(myOtherMethod)) withObject:nil waitUntilDone:YES];
The optional third parameter will hold up the main thread for you if you want it to do so.
Hope that helps!
It depends on what you are trying to do, but I would start with NSOperation and NSOperationQueue. It makes it pretty simple to hand off background tasks. Take a look at Dave Dribin's blog post on NSOperation concurrency as well: http://www.dribin.org/dave/blog/archives/2009/05/05/concurrent_operations/
Instead of blocking the user interface by making it hang, I would suggest showing some kind of loading screen until you've received your first update. The could would look something like this:
- (void)viewDidLoad {
...
[myCLLocationManager beginUpdates];
[self showLoadingIndicator];
....
}
- (void)locationManager:(CLLocationManager *)manager didReceiveUpdates {
[self hideLoadingIndicator];
// Additionally load the rest of your UI here, if you haven't already
}
Don't quote me on those method calls verbatim, but that's how I suggest solving your problem, in essence.
Yes there is an NSCondition object, and it will probably do exactly what you want for the CoreLocation scenario you mentioned.
Is it acceptable for a instance method of a class to release itself?
ie to have a method that calls:
[self release]
Assume that my code is not going to access self after calling [self release]
Is it acceptable for a instance method of a class to release itself?
ie to have a method that calls:
[self release]
Assume that my code is not going to access self after calling [self release]
First, I would want to have a really good reason to release myself. The only time I've done it is in a singleton that I dump to free up large chunks of memory on an iPhone. This is a rare event.
Your code is part of the class object. Hence, it is not really a problem to call [self release]. Of course, you are much safer, from an encapsulation perspective, if you call [self autorelease]. At least then, if someone up the call chain calls your methods, you don't cause an exception.
Andrew
You should only do this if you've done something like
[self retain];
But it's unclear why you would do that. The Cocoa Memory Management Documentation might help
While I doubt that immediately after your release, memory would move much, keep in mind that the code that your [self release] is in, resides in a memory block inside your object, self. Thus, it is possible that after returning from [self release], you end up in code that is no longer allocated and is being written over by some other process. Can't say for sure how probable that is, but it seems possible.
I have used this technique once before, for a similar situation (standalone object handling response from a web delegate that may outlive the view that launched the request).
It does work, but is actually rather tricky to get right. Since then I have found that using NSOperations in an NSOperationQueue is a much more solid and well-understood approach to encapsulating background actions that run independent of the requestors. Usually when an operation is done a notification is sent out on the main thread informing whatever caller might still be around that data is ready for pickup.
Plus for simple remote requests you can use the simpler synchronous URL calls in your Operation since they run in a separate thread and will not block the main thread while data is incoming (handy when fetching small images from URL's, for example).
You can do it. It works. It is a bit dangerous, especially since optimizing compilers can rearrange your code in ways you didn't intend them to.
A little bit safer is to call [self autorelease], which will release the current object at some point in the near future (the next time through the runloop typically) rather than right away.