(Sorry, re-sending with the appropriate subject. Stupid copy & paste failed, my
bad).
>> On Jul 16, 2010, at 3:46 PM, Rafael Cerioli <rafael.ceri...@gmail.com> wrote:
>>
>>> Hi everybody,
>>>
>>> What would be the most efficient way to download data without blocking the
>>> UI (I'm targeting old iPhone/iPod devices) ?
>>>
>>> - using a NSURLConnection seams nice, but as it calls its delegate
>>> (-connection:didReceiveData:) on the main thread, it has to take a lock on
>>> the main thread some times, hasn't it?
>>
>> No. Read up on NSRunLoop.
>
> I guess I had something wrong, NSURLConnection does not do anything in a
> background thread. It just operates in the main thread but "asynchronously"
> thanks to the run loop.
> Quote from NSURLConnection class reference :
> "At creation, a connection is scheduled on the current thread (the one where
> the creation takes place) in the default mode"
>
> That means, there is a lot of work done in the main thread. Even if the
> connection is not scheduled in the runloop "tracking" mode (for the UI), I
> guess the app would slow down at some point.
Unfortunately, I can't find the sources at the moment as it was a while ago,
but there was an interesting discussion about this topic on the macnetworkprog
mailing list. Apple found in the early days of iPhone programming that threads
are (in general), a bad idea for networking, and it was made worse by the fact
that the iPhone has only 1 CPU. Apple's resident kernel networking engineers
(the guys that would know about networking latency the most), as well as the
venerable Quinn "the Eskimo" from Apple DTS, basically boiled it down to this:
Rule #1. Networking code is dominated by network latency, not CPU
cycles.
Rule #2. Don't use threads for networking without thoroughly profiling
your application.
Downloading a file, even if it can be done in a single TCP packet (after the
RTT of the handshake) can take 20-30 milliseconds easily, and that's if the
server responds instantaneously and no DNS lookup is involved. Your application
only gets 10 milliseconds of CPU time anyway so it'll sleep several times
before the file is received, and that's if a bunch of other things are true
first.
Your application, if well behaved will never notice network latency. On the iOS
devices, setting up a thread (creating the thread context, scheduling it in the
kernel and context switching to the new thread) can take a full thread quantum.
GCD helps but only so much.
Now, when SSL gets involved things are murkier. The certificate exchange can
take 100's of milliseconds and is moderately CPU intensive (compared to the
network data transfer which is relatively insignificant). It still all happens
in the background (when using NSStream) and your application should get ample
CPU time, but if you have several connections at once you could find your app
getting slowed down.
If, and only if, you find your application is being blocked by threading
(usually the result of SSL negotiation) then you should think about threading
your networking. Otherwise, trust the threading model of the higher level
networking APIs.
_______________________________________________
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
