Jamie, I hadn't thought about that situation but I can see how that could lead to problems. I guess I will just need to rethink my code a little bit but I will probably do what you suggest and check if the operation has been cancelled in the callback.
Thanks, Chase On Mon, Feb 14, 2011 at 9:18 AM, James Montgomerie <[email protected]> wrote: > I think you are exposing yourself to a race condition here, even if you did > get this to work - imagine: > >> --------------------------- >> // Some Code: >> - (void)myOperationInController; >> { >> // Do stuff >> if (![self isCancelled]) > > <-- main thread sets isCancelled to YES --> > >> [self performSelectorOnMainThread...] >> } > > > Presuming you're not saying "waitUntilDone:YES", a similar thing could also > happen if the main thread sets isCancelled after your > myOperationInController method has returned, but before the queued method > call created by the performSelectorOnMainThread... on the main thread's run > loop is actually executed. > > Since you're going to have to deal with the fact that supposedly cancelled > operations may initiate the performSelectorOnMainThread's callback (to fix > this edge case), a simpler approach to the whole problem might be to /always/ > performSelector..., even if the operation is cancelled, and deal with > (probably just ignore) 'cancelled' operations in the callback itself. > > Jamie. > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
