Easily reproduced doesn't always translate into guaranteed to occur.
In my experience, using a single queue in your application is a
sufficient safeguard as no system framework I've encountered causes an
issue. That isn't to say that the API is without quirks but they can
usually be adjusted to easily enough... (in short, one can endlessly
debate whether or not it's safe to use NSOperationQueue or one can use
it and ship a product a great deal quicker than if they hadn't and
join a number of other applications churning data in large
installation bases).
If you really dislike the idea of it that much, I'd suggest adopting a
similar approach to the API while implementing your own queue. Mike
Ash has done so previously though I don't believe it's a good fit for
what's being talked about here (http://www.mikeash.com/?page=pyblog/raoperationqueue-an-open-source-replacement-for-nsoperationqueue.html
).
As bbum pointed out, the biggest issue that needs to be addressed is
how flexible your code is w/r/t running across multiple cores. In my
experience, thinking in terms of operation objects tends to yield a
high return on investment and enables you to more efficiently
structure your code for parallel execution without shared data
dependencies.
And please remember, 10.6 is unreleased and discussion of what may or
may not be fixed in it is a no-no.
-rob.
On Jan 31, 2009, at 6:34 PM, Andrew Farmer wrote:
On 31 Jan 09, at 15:11, Chris Hanson wrote:
On Jan 31, 2009, at 2:04 PM, jurin...@eecs.utk.edu wrote:
There IS a know bug with the NSInvocationQueue method on intels
using
10.5.6 which I have read will be fixed on 10.6.
Please do not say things like this without citing a specific
source. Otherwise you are spreading rumors.
This developer appears to have isolated a concurrency error in
NSOperationQueue:
http://www.mikeash.com/?page=pyblog/dont-use-nsoperationqueue.html
As noted on that page, it appears to be triggered by attempting to
make use of more than one NSOperationQueue in an application.
_______________________________________________
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/wisequark%40gmail.com
This email sent to wisequ...@gmail.com
_______________________________________________
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 arch...@mail-archive.com
