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 (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
