Re: [OT] Sync vs ASync Server Comms
Re: [OT] Sync vs ASync Server Comms
- Subject: Re: [OT] Sync vs ASync Server Comms
- From: Dave <email@hidden>
- Date: Fri, 22 Feb 2013 13:22:44 +0000
Hi,
Hi,
On 22 Feb 2013, at 11:29, Uli Kusterer wrote:
in short: Network processes can take a long time (high traffic,
14.4k modems, ...). If you are using a synchronous call on the main
thread, your application will be completely blocked from doing
anything else. The CPU will sit there idle, not doing anything
until the transfer has finished. Since the operating system
processes events on the main thread, the user will not be able to
quit your application, click a "Cancel" button or do anything else.
Yes, but that's true of anything that takes, a long time. I didn't
mean the main thread, obviously you can't block that regardless of
what causes the delay!!!
Now imagine you're loading images into a table on an iPhone. The
user is scrolling through the list. Whenever a new item in the
table is exposed, you go out to the network, request that image,
blocking the main thread (and pausing the user's scrolling). At
home, as the developer, you don't notice. The server is sitting
right next to you. But a user at the edge of cell phone reception
or in a moving train will find it impossible to scroll because
essentially he's exposing one item, waiting, exposing the next
item, waiting...
Yeah. but not on the main thread, on a Background thread.
You could solve this problem by using synchronous API on a
separate thread, but threading is hard. That's where async API
comes in. In many cases (e.g. NSURLConnection) these APIs create a
new thread, that does all the synchronous download calls for you,
and then notifies the main thread when it's done. You don't need to
use locks, or semaphores, or do the threading yourself. Other async
calls work by splitting their work into small bits, adding them to
a queue, and then periodically (but on the main thread) performing
a tiny fraction of the work by executing the next tiny fraction of
a task from the queue. In between these tiny operations, the user
can keep working, and barely notices the tiny interruptions.
How is threading hard in this case? Given that you have to make sure
you don't block the main thread anyway, you'd automatically do time
consuming things on a Background thread. It's as hard as [self
performSelectorInBackground..... ];
The App I am working on in highly multi threaded app and all time
consuming work in run on a background thread as a matter of course.
Dave
Cheers,
-- Uli Kusterer
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
On Feb 22, 2013, at 11:13 AM, Dave <email@hidden> wrote:
Hi All,
I was reading an article about Server/Client communications using
a Rest service and the author seemed to have a downer on using the
Sync (as opposed to ASync) methods of making a request and
receiving a reply. Also I've noticed it being generally
discouraged in quite a few other places when I was searching for
3rd Party Network Libraries. However, I can't find any reason
behind it? Does anyone have any idea why ASync transactions are
better than Sync transactions? Or is it just Sync'ism? lol
Have a Good Weekend!
Thanks
Dave
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
email@hidden
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden