Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
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 (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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
On 5/29/09 2:25 PM, Ben Trumbull said: You can download the debug version of Core Data from ADC and use the multithreading assertions. Not if you're using 10.5.7 you can't. :( The 'Debug and Profile Libraries' for 10.5.7 are still unavailable. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
[Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
Hi ! I'm having strange crashes in my threaded core data application. Happy WWDC is in few days! Core Data multithreading basic rule is to avoid passing managed objects across threads, and pass objectIDs instead. 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. 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... Isn't it a violation of the basic rule described below? Aurélien, Objective Decision Team ___ 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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
On Fri, May 29, 2009 at 2:25 PM, Ben Trumbull trumb...@apple.com wrote: 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. Can we please have some further clarification on this in the docs please? r.6933634 Thanks, --Kyle Sluder ___ 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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
On May 29, 2009, at 2:46 PM, Kyle Sluder wrote: Can we please have some further clarification on this in the docs please? r.6933634 The documentation states explicitly: You can use this method to, for example, update a managed object context on the main thread with work completed in another context in another thread. You must, though, lock the receiver or otherwise ensure thread safety (that is, the notification contents are handled safely by Core Data, but the receiver's usage is still expected to conform to the standard Core Data threading policies). For example, you might implement a method to handle a notification that a worker thread had finished saving as follows: http://developer.apple.com/documentation/Cocoa/Reference/CoreDataFramework/Classes/NSManagedObjectContext_Class/Reference/Reference.html#//apple_ref/doc/uid/TP30001182-SW8 Could you elaborate on what is unclear? mmalc ___ 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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
On Fri, May 29, 2009 at 2:59 PM, mmalc Crawford mmalc_li...@me.com wrote: Could you elaborate on what is unclear? Perhaps it would suffice to just have a simple one-liner that mentions NSManagedObjectContextDidSave, specifically in the context of multi-threaded Core Data. It's not an easy topic, so I think an airtight and direct guarantee (not qualified with any for examples or such) that this method is able to use the managed objects contained in a notification received on another thread, along with a link to the NSManagedObjectContextDidSave (which also has a link back to -mergeChangesFromContextDidSaveNotification:) and a caution about the perils of using managed objects belonging to another thread's MOC yourself, would be helpful. And if it's determined to already be clear enough, please close the bug, don't just leave it hanging like a lot of others. Thanks very much. :) --Kyle Sluder ___ 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
Re: [Core Data] mergeChangesFromContextDidSaveNotification: and thread safety
On May 29, 2009, at 3:40 PM, Kyle Sluder wrote: And if it's determined to already be clear enough, please close the bug No, there is something there to be addressed -- thanks for the clarification. mmalc ___ 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
