site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com On 2010 Mar 31, at 14:39, Mike Abdullah wrote:

[self cancelAllOperations]; [self waitUntilAllOperationsAreFinished];

Cancelling the operations is asynchronous since an in-progress op may take a little while to finish up.

OK, but does -cancelAllOperations ultimately remove all operations from the queue? From documentation: "This method sends a cancel message to all operations currently in the queue. Queued operations are cancelled before they begin executing." Does "are cancelled before they begin executing" == "removed from queue"? Maybe Ken explains this... On 2010 Mar 31, at 14:43, Ken Thomases wrote:

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.

So Ken I believe you're saying that the "cancelled" operations become ready to run immediately, which they do (as no-ops), which removes them from the queue. In *effect* therefore, "are cancelled before they begin executing" *does indeed* == "removed from queue". But maybe this is not true in 10.5?

...

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.

Yes, I thought it looked pretty good.

...

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.

Duh. Turns out that the method in which the code was executing was itself an operation running on the main thread. Thanks for the help with this! _______________________________________________ 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/site_archiver%40lists.apple... This email sent to site_archiver@lists.apple.com