Re: Unconventional memory leak problem
Re: Unconventional memory leak problem
- Subject: Re: Unconventional memory leak problem
- From: John Stiles <email@hidden>
- Date: Wed, 6 Sep 2006 16:03:03 -0700
On Sep 6, 2006, at 3:53 PM, Raffael Cavallaro wrote:
On Sep 6, 2006, at 6:10 PM, Rodney Kennedy wrote:
2) When wanting to do drawing from a secondary thread typically
you call performSelectorOnMainThread:(SEL)aSelector
withObject:waitUntilDone: If you do so then in principle every
such aSelector needs to have its own NSAutoreleasePool, just as
you would if you had code that generated a lot of autoreleased
objects (such as in a loop with a lot of iterations) or you had a
secondary thread. This isn't elegant either. I haven't tested
this solution but it will wrap the offending allocations.
Why do you say "in theory." Either you need the autorelease pool or
you don't (in my experience, you do - the console messages I get
saying "yada yada yada just leaking" were my hint).
It isn't any more inelegant than any other sort of Cocoa memory
management (i.e., it's all pretty inelegant by modern standards -
we've had performant, real garbage collection in a number of other
languages for a couple of decades now). Cocoa memory management is
more automatic than, say c, but less automatic than real garbage
collection (which we're finally getting in Objective-C 2.0 <Yay!>).
You still have to do some things manually, and alloc/initing
autorelease pools is one of them.
Those more experienced with Cocoa please correct me if I've gotten
hold of the wrong end of the stick here.
I think you need to re-read the OP's root problem. His issue wasn't
the lack of a pool. In his case, there is an autorelease pool in
place, but it is not being drained until the event loop sees user
activity.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden