• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: [OT] Sync vs ASync Server Comms
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OT] Sync vs ASync Server Comms


  • Subject: Re: [OT] Sync vs ASync Server Comms
  • From: Uli Kusterer <email@hidden>
  • Date: Fri, 22 Feb 2013 12:29:32 +0100

Hi,

 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.

 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...

 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.

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:
>
> 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

  • Follow-Ups:
    • Re: [OT] Sync vs ASync Server Comms
      • From: Dave <email@hidden>
References: 
 >[OT] Sync vs ASync Server Comms (From: Dave <email@hidden>)

  • Prev by Date: Re: A plugin for a sandboxed app - where to can I successfully store a temp file?
  • Next by Date: Re: A plugin for a sandboxed app - where to can I successfully store a temp file?
  • Previous by thread: [OT] Sync vs ASync Server Comms
  • Next by thread: Re: [OT] Sync vs ASync Server Comms
  • Index(es):
    • Date
    • Thread