Re: NSMutableArray + NSEnumerator = No Memory
Re: NSMutableArray + NSEnumerator = No Memory
- Subject: Re: NSMutableArray + NSEnumerator = No Memory
- From: James Bucanek <email@hidden>
- Date: Mon, 24 Sep 2007 09:57:48 -0700
Philip Q <mailto:email@hidden> wrote (Monday,
September 24, 2007 12:10 AM +1200):
On 23/09/2007, James Bucanek <email@hidden> wrote:
I was eventually able to isolate the problem; My application is
running out of memory. The crash occurs at
NSMutableArray* files;
...
NSEnumerator* e = [files objectEnumerator]; <-- crashes in
CFArrayGetValues > __memcpy
I think the problem is that you are using an NSMutableArray:
Glenn Andreas confirmed that this occurs with immutable arrays too.
The contents of a mutable array can be modified at any time, this is
problematic for an enumerator as if the array is modified while it is
enumerating through it, it could end up skipping elements or some
other funky behaviour (even thought the documentation discourages this
type of modification).
The behaviour you're seeing is a way to combat that---make a copy of
all the references in the array at the time of creation of the
enumerator and enumerate though that list (which will never change).
There are two problems with this theory:
(a) It this were true (and I totally understand what you're
saying -- I've written collection classes that do something
similar), why doesn't it happen all the time? According to this
theory, any enumerator would have to first take a snapshot of
the collection before it could begin. Of course, I'll temper
this by saying that there could be some lazy optimization (where
the first enumerator just sets a flag and the second one forces
a copy, etc.). But reason (b) makes this all a moot argument.
(b) The Cocoa collection classes are clearly documented as *not*
supporting modifications to the collections during an
enumeration. All clearly state that changing the underlaying
collection is not supported and will result in undefined
behavior. If you need to modify a collection during an
enumeration, it's the programmer's responsibility to make a copy
of it first.
What I suspect is that there's some code in the Cocoa framework
that trying to provide safe enumerators: enumerators that are
stable while the collection is concurrently modified. This might
be new code added to support this, or code that was just left in
the framework after it was decided that the collection classes
can't/don't support this pattern.
--
James Bucanek
_______________________________________________
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