On Sat, Jan 31, 2009 at 10:15 PM, Robert Marini <email@hidden> wrote:
> 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).
Or one can waste days tracking down an intermittent bug that only
shows up rarely, only to discover that it's entirely out of your
control. There are many choices! Of course, now that the problem is
known, hopefully googling the error message will actually get results,
leading to a much faster debugging session.
> 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
RAOperationQueue's single-threaded nature means that an individual
queue will get no speedup from multiprocessing. If you can, through
whatever means, involve multiple RAOperationQueues in your computation
simultaneously, each one will potentially run on a separate core.
However, RAOperationQueue is meant as more of a
synchronization/background processing mechanism rather than a
performance enhancer, so its design does not do much in that
> And please remember, 10.6 is unreleased and discussion of what may or may
> not be fixed in it is a no-no.
Technically, you can discuss it (although probably not here) as long
as you're uninformed about it. Which means the best you can hope for
is unsubstantiated rumor, which is not generally a good idea. As I
said in another thread today, those who know can't say, and those who
can say don't know. Unless you see it coming from an apple.com
address, don't believe it!
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