Re: memory leak in readInBackgroundAndNotify
Re: memory leak in readInBackgroundAndNotify
- Subject: Re: memory leak in readInBackgroundAndNotify
- From: "Gurmit Teotia" <email@hidden>
- Date: Fri, 21 Apr 2006 16:33:30 +0530
Thanks Greg & Ondra. I think I've to read more to clear my understanding.
But still this behaviour is confusing to me. For time being I have use
nested autorelease pool. Later on when I get more familiar with it, I think
I'll be able to understand where is the problem.
Regards,
Gurmit
On 4/20/06, Ondra Cada <email@hidden> wrote:
>
> Gurmit,
>
> On 20.4.2006, at 7:34, Gurmit Teotia wrote:
>
> > Now my first question: Is a autorelease pool is also created before my
> > method is called back through notification?
>
> At the very beginning of NSAutoreleasePool documentation (actually,
> in the second paragraph) you can read
>
> "The Application Kit creates a pool at the beginning of the event
> loop and releases it at the end".
>
> So the answer is "rather not, unless NSFileHandle takes care of
> that". Since NSFileHandle is not documented so (which can be
> determined in five-odd seconds by searching its description for
> "pool"), you canot assume that (it might, perhaps, sometimes, when it
> chooses so, but there's no guarantee).
>
> Therefore and self-evidently, if you are creating a lot of big
> autoreleased objects in the notification handler and/or if you assume
> it could be called many times inside one event loop, it is your
> responsibility to release them. The best, most flexible and most
> failproof way is to create a nested autorelease pool:
>
> -(void) receivedData: (NSNotification *) notification {
> NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
> ... whatever ...
> [pool release];
> }
>
> Alternatively, you can explicitly pair alloc/init and release as Greg
> adviced, but (a) that's somewhat error-prone, (b) other methods you
> may use can autorelease internally, and thus the above is ways better
> (but for a very small minority of quite special cases).
>
> > Instance Browser in ObjectAlloc clearly show each allocated
> > instance of
> > "mData"and it is never released.
>
> They should be released as soon as the current event loop ends and
> another begins. If they are not, it would indeed be a bug (but I
> doubt it very strongly, since I've used readInBackgroundAndNotify
> pretty often, and my objects were always released at the event loop
> break all right:))
>
> > This for Apple guys if any of them wathching this thread.
> > Apple documentation seriously lacking the vital information for
> > understanding the Cocoa framework. It's very difficult for a newbie to
> > easily grasp the concept. It is very very general in concept. In
> > one line
> > you people finish the description. It is more like a directionless
> > hint.
>
> Matter of fact, the documentation is extremely good. In this case,
> the very information you needed happened to be at the very beginning
> of the doc for the very class you wondered about: it can't get any
> better.
> ---
> Ondra Čada
> OCSoftware: email@hidden http://www.ocs.cz
> private email@hidden http://www.ocs.cz/oc
>
>
>
_______________________________________________
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