On Dec 4, 2012, at 11:46 PM, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote:
> When I add 8 or more operations to NSOperationQueue (using > NSOperationQueueDefaultMaxConcurrentOperationCount concurrent ops) , > - then switch to some other app, > - then try to make my app active again, I get a beach-ball. > My app becomes responsive again, when all operations have finished. OK, that is nuts, and seems to confirm what Kyle said on one of the many other threads you started: >> NSOperationQueue uses KVO for dependency tracking and queue width >> management. In 10.7, the implementation was apparently changed to thunk all >> KVO ops onto the main thread; I'm guessing this fixed a bug by serializing >> all state changes. It sounds like the large numbers of isCanceled calls your operation is making are somehow causing activity on the main thread that’s blocking other stuff. Very weird. PLEASE take a sample of the app while it’s in the beachballed state and look at what’s going on on the main thread and the GCD threads used by the operation queue. That should give clues about what’s happening. —Jens _______________________________________________ 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
