Re: Unexpected behaviour with autorelease pool
Re: Unexpected behaviour with autorelease pool
- Subject: Re: Unexpected behaviour with autorelease pool
- From: "Michael Ash" <email@hidden>
- Date: Sun, 14 Dec 2008 18:13:15 -0500
On Sun, Dec 14, 2008 at 5:38 PM, Filip van der Meeren
<email@hidden> wrote:
>
> On 14 Dec 2008, at 23:27, Ken Thomases wrote:
>
>> On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote:
>>
>>> If your system doesn't crash/hangs before you can stop it, then you will
>>> see that the app is consuming memory like the Americans are consuming oil.
>>> And according to me, my program respects the Memory Management rules. So
>>> I say there is a bug.
>>
>> Then you misunderstand. Nothing in the Memory Management rules will
>> protect you, your program, or the system against your program consuming
>> large amounts of RAM or VM.
>>
>
> The Memory Management won't protect me indeed, but still, NSNumber is the
> basic foundation of our OS, I know dozens of ways to create the object
> without autoreleasing it inside somewhere.
> There has to be a better way to do this, this isn't just some other virtual
> machine that releases objects when its pool is full. This is native, no
> garbage collector is going to save us!
> That is why I think that the basic building blocks of our framework should
> be able to create themselves without putting a big restraint on the system.
There is no big restraint on the system. If you have a long-running
loop such as in your example code then you *must* create and destroy
inner autorelease pools within the loop if you intend to keep memory
consumption at reasonable levels. This is documented and discussed,
and should hardly be a surprise. That you alloc/init your objects
instead of using convenience constructors is no surprise. You *cannot*
rely on code you do not control not to autorelease objects just
because you're using "direct" methods.
Follow the rules. It's the only way. The rules say that you need an
autorelease pool in a tight, long-running loop. You can't ignore that
just because you think you shouldn't need it in this particular case.
Mike
_______________________________________________
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