Re: Canceling NSInvocationOperation
Re: Canceling NSInvocationOperation
- Subject: Re: Canceling NSInvocationOperation
- From: Chase Latta <email@hidden>
- Date: Mon, 14 Feb 2011 09:44:22 -0800
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@hidden> 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@hidden)
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:
This email sent to email@hidden