On Oct 29, 2009, at 9:00 AM, Alastair Houghton wrote:
If you insist on using threading, then yes, you could do this in the background with an NSOperationQueue (or by using NSThread directly). As for Foundation objects and thread-safety, note that immutable objects generally *are* thread-safe, but mutable ones generally aren't. So NSString is, but NSMutableString isn't.
Also, it's generally safe to use even mutable Foundation objects in a single thread. So for example you could create an NSMutableString on a background thread and mess with it all you want on that thread.
This fits in with the growing consensus about parallelism, that it's best to avoid sharing data between threads. Pass a minimum amount of data to the background task using immutable objects, and have it return results similarly. Make the background task stateless, using only the data that was passed in and not any global state.
On the other hand, if you run the download on a background thread you're going to have to register some kind of callback in the main thread to be invoked when it finishes, and pass the downloaded data (and any error state) to the callback. This ends up being pretty much equivalent to what you'd do to use NSURLConnection's asynchronous mode, plus you have to implement some of the infrastructure yourself. Why not just use the async mode?
Basically, concurrency is not free. You have to do some work to achieve it, whether you use threads or dispatch queues or asynchrony. Having your activity indicator update during the download counts as concurrency :)
—Jens_______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
