Re: memory leak in readInBackgroundAndNotify
Re: memory leak in readInBackgroundAndNotify
- Subject: Re: memory leak in readInBackgroundAndNotify
- From: Ondra Cada <email@hidden>
- Date: Thu, 20 Apr 2006 08:08:28 +0200
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