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]
