On Jun 8, 2008, at 7:26 PM, Wayne Shao wrote:
So what exactly I should do in the start() method??
I think if you don't know, then you shouldn't be configuring your
operation as concurrent.
I think that Apple chose badly in describing operations as
"concurrent". What that really means is an operation that has a need
to manage its own execution context. If you have such a need, it's
expected you know what to do in the start method -- that is, the
start method establishes the "custom" execution context.
Note that if you don't make your operation "concurrent" in this
sense, but you queue it in an NSOperationQueue, that queue will still
run it asynchronously, in its own thread, concurrently with other
operations. It's just that, for non-"concurrent" operations,
NSOperationQueue knows it has to manage the execution context itself
(by spinning off a thread).
If I create a thread,
does the operation queue still enforce maxConcurrentOperationCount
or I need
to worry about that in my implementation?
If you do go ahead and implement a "concurrent" operation, then the
queue still enforces its own maxConcurrentOperationCount. The only
difference is that the queue is relieved of the responsibility of
putting your operation in its own thread.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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]
