On 22 Feb 2013, at 15:48, Fritz Anderson wrote:
On 22 Feb 2013, at 8:56 AM, Dave <d...@looktowindward.com> 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)
Of course there are threading "issues"!!!! Having delegates doesn't
stop that and running a delegate on the main thread is not always the
best thing to do. Also with this approach, if the delegate want to do
another lengthy operation then you get delegates within delegates and
the whole thing becomes a giant mess.
You get none of this if you toss a synchronous call into a
dispatch_async() and call it a day.
As long as you are not running on the main thread there is no real
difference between a Sync or ASync operation as far as any of the
issues you mention above are concerned.
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.
You don't have to take the example so literally! If I called the
methods:
-(someValue) syncGetValueFromServer
{
// Get Value From Server - takes a long time.
return Value;
}
-(void) aSyncGetValueFromServer:
{
// Get Value From Server - takes a long time.
}
It would amount to exactly the same thing! You are making a common
mistake of making conclusions about the method you are calling! It
may well be better with an Operation queue, but that's not the point
or the question! The question is you have two black box methods that
do the same thing, one has Sync in it's name the other has ASync in
it's name. Given everything else is equal (which is is in this case),
which one would you choose and why?
Take Care
Dave
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
