• 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: Fritz Anderson <email@hidden>
  • Date: Fri, 22 Feb 2013 09:48:06 -0600

On 22 Feb 2013, at 8:56 AM, Dave <email@hidden> wrote:

> A (Background) thread has two choices at this stage:
>
> 1.  Call aSyncComputePIToAZillionPlacesWithDelegate and provide a delegate that will be called back with the result.
>
> 2.  Call syncComputePIToAZillionPlaces get the result inline.
>
> As long as the Background Thread doesn't have more work to do in parallel with the Compute PI operation, why is option 2 better than option 1.
>
> I think that option 1 is by far the best solution and I can't understand why anyone would choose option 2!!

You misconceive what Apple and the other replies are telling you. The whole point of the async API is that _you don't create a background thread at all._ You call the method that starts the async process on the main thread, the implementing class does all the background processing as/if needed (and does it correctly), and it reports progress, errors, and completions on the main thread.

You get:

* No threading issues (Apple has already done them correctly)
* A service that can make an optimal choice between a background thread and a runloop source
* The ability to cancel (no threading issues)
* Progress events (no threading issues)
* The ability to detect security issues on-the-fly (no threading issues)
* Authentication (no threading issues)
* Error handling (no threading issues)
* The ability to interface with your controllers and views in a way that is factored out of the asynchronous process into your main-thread delegate methods (no threading issues)

You get none of this if you toss a synchronous call into a dispatch_async() and call it a day.

That's only what I can think of for NSURLConnection; your example of a calculation of pi is simplified to the point of being a straw man, and better handled with an NSOperation.

	— F

--
Fritz Anderson
Xcode 4 Unleashed: 4.5 supplement for free!
http://www.informit.com/store/xcode-4-unleashed-9780672333279


_______________________________________________

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>)
 >Re: [OT] Sync vs ASync Server Comms (From: Uli Kusterer <email@hidden>)
 >Re: [OT] Sync vs ASync Server Comms (From: Dave <email@hidden>)
 >Re: [OT] Sync vs ASync Server Comms (From: Uli Kusterer <email@hidden>)
 >Re: [OT] Sync vs ASync Server Comms (From: Dave <email@hidden>)

  • Prev by Date: Re: IOS iPad PopOver Nav bar color
  • Next by Date: Re: iOS books, etc for experienced OSX programmers
  • Previous by thread: Re: [OT] Sync vs ASync Server Comms
  • Next by thread: Re: [OT] Sync vs ASync Server Comms
  • Index(es):
    • Date
    • Thread