On 25 Feb 2013, at 22:45, Steve Sisak wrote:
At 3:18 PM +0000 2/25/13, Dave wrote:
On 25 Feb 2013, at 13:57, Steve Sisak wrote:
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.
Why? I use them for some very high performance stuff.
Because of the path the code follows depending of responses from the
server(s) and also because the code is fairly dynamic in that data
can be added without updating the code base, this makes predefining
the operation queue conditions is much harder to implement and much
harder to read and maintain.
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.
The current trend is away from threads and toward asynchronous
programming.
That's orthogonal to whether your tasks are run on a single
(XXRunLoop) or multiple (GCD) threads -- the advantage of GCD is
that the system gets do decide how many worker threads to fire up
based on the number of cores available, system load, and who's
blocked.
NSOperationQueue adds dependencies -- you can do similar things
with blocks and dispatch_groups.
If you don't like NSOperationQueue, go bare metal and use GCD
directly.
Yes, I am internally.
I suggested NSOperationQueue because it's exactly the right tool
for your example.
WAYRTTD?
-Steve
_______________________________________________
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
