On Mar 31, 2010, at 4:32 PM, Jerry Krinock wrote: > [self cancelAllOperations] ;
> So you see in NSLog #1 there are 5 operations in the queue. This is > expected, because although the documentation for -cancelAllOperations is a > little vague, it does not say that it *removes* any operations from the queue. -cancelAllOperations iterates over the operations in the queue and invokes -cancel on each, more or less. All that -cancel does is mark the operations as canceled. Then, it is up to the operation to check the isCancelled property and finish as soon as possible. The default implementation of -start (for non-concurrent operations) does this before even getting started. As of Snow Leopard, -cancel also makes the operation ready, regardless of any unfinished dependencies it may have. So, the queue is free to start any canceled operations. However, the queue obeys its usual constraints. If it has a maximum number of concurrent operations and it is already executing that many, it will have to wait to start the ones you just canceled. Even if it doesn't have a hard maximum, the kernel may not assign it a free worker thread if load is high. Etc. In any case, there's no guarantee as to how fast this will happen from the point of view of another thread. > P.S. The above code is executing on a secondary thread. Is that a possible > issue? NSOperationQueue is not listed as a thread-safe class in the > Threading Programming Guide. But in the class documentation it says "It is > safe to use a single NSOperationQueue object from multiple threads without > creating additional locks to synchronize access to that object." That's an explicit guarantee that NSOperationQueue is totally thread-safe. > I tried running the above code with performSelectorOnMainThread wrappers, but > got a deadlock I can't explain either. (Sample shows mach_msg_trap.) You can look at the stack traces a bit further down. I suspect you have multiple inter-dependent things both trying to perform a selector on the main thread and blocking for the result. Regards, Ken _______________________________________________ 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
