On Aug 30, 2009, at 3:52 PM, Adam R. Maxwell wrote:
On Aug 30, 2009, at 12:12 PM, Ken Thomases wrote:
Well, that's polling and is generally discouraged.
Yes, but Apple's runloop documentation recommends using a timeout:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html
Interesting. Weird, but interesting. :)
While you would have to check [self isCancelled] each time through
the run loop, if you treat cancellation as a message from one
thread to the other then you don't have to set a timeout.
Processing the message from the other thread will cause -[NSRunLoop
runMode:beforeDate:] to return, so you have the opportunity to
check then before looping back around and calling it again.
So in -start, you'd be running the runloop with +[NSDate
distantFuture] as the timeout and stash away the thread as an ivar
for later messaging in -cancel? I admit that I didn't think of
overriding -cancel as you suggest, but either way you end up with a
potential runloop/thread interaction mess.
Right, that's why I warned that it would be non-trivial.
Personally, I think NSOperation[Queue]'s usage of KVO is sort of
unfortunate.
Perhaps, although I think almost any alternative mechanism would share
most of the same pitfalls.
Regards,
Ken
_______________________________________________
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]
