On Oct 1, 2011, at 15:06 , Kyle Sluder wrote:
> NSOperationQueue backgroundQueue = /* some long-lived background queue */;
> NSOperationQueue replyQueue = [NSOperationQueue new];
> int totalResult = 0;
>
> [replyQueue setSuspended:YES];
>
> for (id foo in myFoos) {
> [backgroundQueue addOperationWithBlock:^{
> int result = DoSomething();
> [replyQueue addOperationWithBlock:^{
> totalResult += result;
> }];
> }];
> }
>
> [replyQueue waitUntilAllOperationsAreFinished];
>
> /* all done! */
Aren't you missing a [replyQueue setSuspended: NO] in there somewhere? And if
you do that, aren't you then failing to wait for backgroundQueue to empty?
> But this falls apart if -waitUntilAllOperationsAreFinished doesn't
> look at -isSuspended, and it gets called before the first operation
> gets enqueued on the replyQueue.
I can't see anything that justifies an assumption that isSuspended has any
effect on the wait. Occam's Razor says that the wait returns immediately if the
queue is empty.
> I can easily work around this by enqueuing a no-op operation on
> replyQueue right after calling -setSuspended
Why not use [backgroundQueue addOperations: … waitUntilFinished: YES], then
[replyQueue waitUntilAllOperationsAreFinished], and forget about isSuspended?
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
