Question

I’ve noticed that if I create an NSURLConnection and fire the request, all is well. My delegate methods get called and the last delegate method get’s called well after the code block invoking the connection completes. Great.

That leads me to believe the connections are asynchronous which implies that they’re multi-threaded. Is that correct? Could they be asynchronous but in the same thread? No, that’s crazy – right?

But, in every example I’ve seen using an NSOperation, NSURLConnections are always scheduledInRunLoop after which [runLoop runMode …] is invoked in a while loop.

Can someone explain exactly what is happening here? It seems to me that the first case requires spawning secondary threads but no manual invocation of the run loop (on those threads) while NSOperation (in a new thread) does require manual invocation of the run loop.

Why is no manual invocation required for the first case?

Answer 1

NSURLConnection does spawn a single background thread to manage all instances of itself, but this is generally irrelevant to the caller, since the delegate calls are made on whatever thread owns the runloop the connection was scheduled in. (This fact turned out to be very relevant to me recently, but these things really only come up when dealing with insane crashers in multi-threaded apps.)

For more caller-relevant details, you should look at the docs for -[NSURLConnection scheduleInRunLoop:forMode:]. It explains how to manually handle scheduling and unscheduling, and how NSURLConnections behave in a multi-threaded environment.

If you are unclear on how run loops work and how they perform asynchronous actions without requiring additional threads, you should read Run Loops in the Threading Programming Guide. This is a very important topic for moving to more advanced Cocoa development.