Re: NSOperationQueue question
Re: NSOperationQueue question
- Subject: Re: NSOperationQueue question
- From: Quincey Morris <email@hidden>
- Date: Fri, 7 Aug 2009 16:43:55 -0700
On Aug 7, 2009, at 16:07, Tim Murison wrote:
I enqueue operations until ~1000 have executed, then wait for the
queue to
be empty. Then sleep for 10 seconds and force a collection. Once the
queue
is empty there should be a maximum of 4 outstanding operations (the
concurrency count). 10 seconds should be plenty of time to finish
servicing
them.
Needless to say, I still get the memory increase. I don't with
retain/release code. This isn't a hypothetical question, I do have a
real
program with real operations that exhibits this behaviour, and
unfortunately
it is not written for retain/release.
OK, assuming that there aren't any other factors affecting the
"quiescence", then what you have now is a good sample application to
submit with a bug report.
I understand that's not an answer that looks like it gets you
anywhere, but ...
-- It's possible that you might actually get a response to the bug
report that explains what's going on, and that might be helpful to you.
-- What are your options from proceeding from here anyway? If there's
a defect in the frameworks end of this, it could end up never being
fixed in Leopard, so you're going to have to coexist with it and find
a workaround.
-- Although it's true that Instruments/Leaks may be of no use,
Instruments/Object Allocations should still be a usable tool for
investigating exactly what memory is lingering. After all, it's not
like your test application is using much of anything else to clutter
up the analysis. If you can find out what memory is involved, you may
well have found out the workaround.
-- At the very least, you should consider reconfiguring your *real*
application to avoid generating lots of pending operations. (For
example, limit yourself to, say, 8 NSOperations in existence at one
time, regardless of the capacity of your NSOperationQueue.) If you
still have a problem, you could reconfigure your test application
similarly, to find out if it has the same problem as before (but just
more gradually).
-- You could try using Mike Ash's RAOperationQueue instead:
http://www.rogueamoeba.com/utm/2008/12/01/raoperationqueue-an-open-source-replacement-for-nsoperationqueue/
even though it's a workaround for a different problem (presumably).
The value of that solution is that it moves things out of the
frameworks into 3rd party code where you have some hope of tracking
down what's going on yourself. It's also possible that the problem
simply won't happen in that case.
HTH
_______________________________________________
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