Re: [OT] Sync vs ASync Server Comms
Re: [OT] Sync vs ASync Server Comms
- Subject: Re: [OT] Sync vs ASync Server Comms
- From: Steve Sisak <email@hidden>
- Date: Mon, 25 Feb 2013 08:57:29 -0500
At 12:26 PM +0000 2/24/13, Dave wrote:
I think I see what you mean, but I'd argue that there are still
"threading" issues, the OS will create the Background Threads and
take care of calling you back on the main thread, I agree, and, if
that's all you were doing, it might be said to have "No Threading
Issues", but, for instance, if the first ASync call, needs data to
use on a later call, then there may well be "Threading Issues".
Example 1:
Kick off ASync Operation A to get DataA.
Kick off ASync Operation B to get DataB.
Kick off ASync Operation C using DataA and DataB - You need to
"worry" about "threading" (or at least the consequences of threading
at this point).
Just to be pedantic, that's a dependency issue but, since the async
operations always complete on the main thread (or the thread you told
them to), you don't have to worry about being interrupted while
manipulation the results.
In the case above, you issue operations A and B, cache the results as
they come back, and as soon as you have both, kick off operation C.
...or you can just use NSOperation, set up your dependencies, and let
the OS do it:
Created A, B, C, make C dependent on A, B, submit all of them to an
NSOperationQueue and wait for C to complete (or put your completion
code on a block dependent on C -- NSBlockOperation makes this really
easy.
See the Concurrency Programming Guide:
<http://developer.apple.com/library/ios/#documentation/General/Conceptual/ConcurrencyProgrammingGuide/Introduction/Introduction.html>
Note that most of this discussion is covered in it.
In fact, I'd argue that using Sync on a user created Background
thread would after a very small learning curve, actually result in
less "Threading" issues but may well suffer performance wise. For
instance in pseudo code, Example 1 would look something like:
You have something which looks like a "simple learning" curve until
you start getting in uncomfortable places.
For a good example of async operations, look at the LinkedImageFetcher sample:
http://developer.apple.com/library/mac/#samplecode/LinkedImageFetcher/Listings/Read_Me_About_LinkedImageFetcher_txt.html
If you want to see how hard the threading issues really are, read the
comments in QWatchedOperationQueue.m -- fortunately, you don't have
to write this, you can just use it.
Also, you don't have to do everything on the main thread -- I
frequently use a (single) background server thread which sits in a
runloop and do everything but the UI from there.
This keeps both you UI and engine responsive.
HTH,
-Steve
_______________________________________________
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