scheduling async downloads in main thread's runloop vs bg thread's runloop on iOS?

Question

Here's a slide from WWDC 2010 session 208:

conn = [[NSURLConnection alloc] initWithRequest:req
  delegate:self startImmediately:NO];
[conn scheduleInRunLoop: [NSRunLoop currentRunLoop]
  forMode: NSDefaultRunLoopMode];
[conn start];

Are there any problems associated with putting multiple conn's in the currentRunLoop?

What benefits does scheduling the NSURLConnection in a background thread's runloop?

Thank you!

Answer 1

Your use of the phrase "secondary runloop" suggests that you don't know what a run loop is.

An NSRunLoop is an implementation of a thread's "main loop". More or less,

while ([runLoop waitNextEvent]) {
    NSAutoreleasePool * pool = [NSAutoreleasePool new];
    [runLoop handleEvent];
    [pool release]; pool = nil;
}

A run loop has a thread. Each thread has at most one run loop. "performSelectorOnMainThread" schedules it on the run loop, but programmers generally talk about threads rather than whatever run loop abstraction it's using, since they're all the same. Not all threads have run loops (NSThread's functions will generally give you a thread with no run loop; I think you have to create the run loop yourself if you want one).

"currentRunLoop" is the run loop of the currently executing thread. This is probably the main thread, unless you've used NSOperation/dispatch_*/etc. If you schedule it on another thread, then (I think) the delegate callbacks get run from another thread. You probably don't want that to happen.

Now, threads.

There is little point spawning a background thread which is idle most of the time. NSURLConnection should to very little processing (you can't get that much bandwidth into a phone in the first place); there's practically no overhead associated with running it in the main run loop; threads tend to have much larger overheads.

If you're processing the data, and the processing is CPU-intensive, you might want it running in the background thread. You might put the connections in the background thread, but in general it's easier to do as much as possible in the main thread.

And I won't get started on inter-thread communication woes, because they're a major pain. Only use concurrency if you know you need it.

(And until the iPhone goes dual-core, you almost certainly don't need it for 99% of the code you write.)