On Oct 24, 2008, at 10:18 PM, Mark Aufflick wrote:
Of course. I was trying to get the default autorelease pool to drain it, but I just need to operate on the defaultCollerctor.Your last piece of advice alomst worked - I had to: [[NSGarbageCollector defaultCollector] collectExhaustively];
I suspect that -collectIfNeeded would work in your long running test case. But there is little harm in calling collectExhaustively as long as you are doing so relatively infrequently. Garbage is garbage afterall and a small heap is relatively cheap to scan.
I'm not doing anything fancy with the runloop - just the Xcode cocoa application template. I set up the observer via [NSDistributedNotificationCenter defaultCenter] addObserver:... in awakeFromNib of a controller. No explicit threads. Do you think that constitutes a radar? It certainly seems like the collector should run since events are being received in the run loop (evidenced by an NSLog in sendEvent).
That *definitely* warrants a radar. It definitely appears that you have a pattern of usage that the collector is not dealing with correctly!
To summarize: You have an application whose sole source of events are [ideally] from NSDistributedNotificationCenter. The collector isn't reaping garbage in this situation with anywhere near the efficiency that it should. It should not require the hint via either - collectIfNeeded or -collectExhaustively.
Thanks so much for your help - I would have beaten release pools to death before I looked at NSGarbageCollector...
Happy to help, b.bum
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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]
