Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
- Subject: Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
- From: Aurélien Hugelé <email@hidden>
- Date: Tue, 2 Jun 2009 10:57:37 +0200
Thanks for the explanation, I like when you have to bend the rules ;)
Aurélien,
Objective Decision Team
On 29 mai 09, at 23:25, Ben Trumbull wrote:
On May 29, 2009, at 2:49 AM, Aurélien Hugelé wrote:
Core Data multithreading basic rule is to avoid passing managed
objects across threads, and pass objectIDs instead.
yup.
To "synchronize" 2 mocs from 2 different threads (sharing the same
psc), I use mergeChangesFromContextDidSaveNotification:. As Apple
demonstrate in the documentation, I use
performSelectorInMainThread: since I just want to synchronize my
main moc, in the main thread, with inserted objects, created in a
second moc, in a subthread. So there is no need to lock.
Ok.
But the mergeChangesFromContextDidSaveNotification: method uses the
notification as an argument, and the userInfo of this notification
contains managed objects, not objectIDs! Managed objects are then
passed from sub thread to mainthread...
This is supported. You may pass the NSNotification object from
didSaveChanges to the mergeChangesFromContext... method on another
MOC even across threads. Of course, if you yank the managed objects
out of the NSNotification and use them in different threads
yourself, that is a violation.
Isn't it a violation of the basic rule described below?
In a literal sense, it can appear that way. The specific
implementation details of mergeChangesFromContextDidSaveNotification
address the paradox. The framework gets to bend its own rules a
touch in much the same way that an object accessing its own private
ivars is still honoring encapsulation.
You can download the debug version of Core Data from ADC and use the
multithreading assertions. They enforce the rules, even on the
framework itself :-)
A lot of strange crashes with threads are actually very complicated
memory management bugs. Something like malloc_history can be very
useful for tracking those down. Instruments as well with its
ObjectAlloc tool can provide stack traces for every retain and
release ever on an object.
- 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