Re: Proper NSOperation isCancelled handling
Re: Proper NSOperation isCancelled handling
- Subject: Re: Proper NSOperation isCancelled handling
- From: Ken Heglund <email@hidden>
- Date: Fri, 13 Feb 2009 15:30:19 -0800
On Feb 13, 2009, at 8:23 AM, Kyle Sluder wrote:
On Fri, Feb 13, 2009 at 8:55 AM, Alex Curylo <email@hidden>
wrote:
Because all -start does is initiate an NSURLConnection. If it's
failing to
connect or whatever, I want the operation to stop when the user
says so, not
whenever -didFailWithError gets around to being called.
That's not what -cancel is supposed to do. -cancel is simply a way to
get -isCancelled to return YES. You check for this at the top of your
thread's runloop, and if it is YES then you abort your operation and
end the thread.
A -cancel override seems to be a fine place to clean up a cancelled
concurrent operation. If the operation's -start method registers for
callbacks, or as a delegate, that needs to be undone at some point
before the operation is deallocated.
In one case, I have operations that register as CFReadStream clients.
A custom -cancel method closes the stream, cleans up the run loop, and
calls [super cancel]. isCancelled KVO notifications are properly
generated with no particular drama.
-Ken
_______________________________________________
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