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: Mon, 25 Feb 2013 15:18:56 +0000
On 25 Feb 2013, at 13:57, Steve Sisak wrote:
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.
This was just a simplistic example, unfortunately in real life it's
not possible to use an Operation Queue effectively for what needs to
be done, and, anyway, the code is much harder to read and maintain to
use one.
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.
Agreed. but that is true of anything, I am comfortable with Multi-
Threading so it's not really an issue for me.
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.
Yes, that's basically the same conclusion I came to, but if do this,
it negates a lot of the initial simplicity of using that approach,
so, at that point it's a toss up on which method is preferable.
Cheers
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