re: Managed Object won't dealloc even after Hit with Kitchen Sink
re: Managed Object won't dealloc even after Hit with Kitchen Sink
- Subject: re: Managed Object won't dealloc even after Hit with Kitchen Sink
- From: Ben Trumbull <email@hidden>
- Date: Mon, 22 Dec 2008 01:36:14 -0800
// Insert a Foo without telling the undo manager
[undoManager disableUndoRegistration] ;
Foo *foo = [[Foo alloc] initWithEntity:runEntity
insertIntoManagedObjectContext:moc];
That's standard alloc/init. It's retained and needs a matching
release from you. Whether or not it's inserted into the MOC is
irrelevant. The convenience method on NSEntityDescription is
autoreleased (it's a class factory method).
// Now, NOBODY has any reason to hold on to foo, so
// when we release the pool, we expect that Foo should
// log a dealloc message:
[pool release];
// Actual result: no dealloc
Quincey's comments are accurate. You'll need a call to -
processPendingChanges after releasing the pool, or just release the
MOC entirely instead of calling reset+processPendingChanges. GUI apps
usually don't have this problem since the event loop will catch this
issue.
The managed objects can't be deallocated immediately if their MOC is
still alive, since they can't know if it's a thread safe time for
their MOC to operate upon them and their dependent resources. They
can't know, because they could be leaked into an autorelease pool,
like this example, while the MOC was handed off to another thread.
Since so much of Cocoa API returns autoreleased results, including -
executeFetchRequest, this scenario is easy to trip over.
On the bright side, NSManagedObject can safely have release invoked
upon it from any thread at any time. On the down side, there is a
transition state in order to safely tear down dependent resources
(release on related objects, row caches, MOC state, etc etc). While
less than ideal, personally, I think this is less cumbersome than the
objects that can only be used on the main thread.
The object may additionally be retained by the MOC if it has pending
changes for the next save operation, or if it is being held within the
object graph by a related object that is not a fault.
- Ben
_______________________________________________
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