On Sep 30, 2009, at 12:56 AM, Luke Evans wrote:
Well, I'm more than happy to file a bug, as it has been tricky to figure out (and I would probably still be at it without your interjection). There are several ways to frame the problem of course: it could be a documentation bug... things aren't as simple as might first appear in the docs/guide, or maybe something can be done to have deleted object behave in a 'friendlier' manner w.r.t. their defunct relationships. I suppose I can just find a general form of words and let you good folks figure out what it really means in practice :-)
Probably some of both.
I still think I might have something more to figure out here too. At the end of my testing, as an experiment I had a main thread timer fire periodically to perform a save on the main thread's MOC (without performing any changes on the main thread's MOC at all). This induced the same problem, and I'm still curious as to how the main thread's copy of the graph might have the nil in the relationship under these conditions. AFAICS there shouldn't have been any chance for either MOC to be in this condition at any time. I assume the merge operation from the other thread is 'atomic' somehow and activity on another thread (like a save) should not be able to catch that MOC in some kind of in-between state?
merge ? I'm not sure I have a full grasp on your work flow here. If you call mergeChangesFromContextDidSaveNotification, then that can obviously make changes to the object graph.
There are two other issues in play. First, if you've set a merge policy, then the MOC may pull in changes necessary to make the save correct (e.g. implement and correct an optimistic locking failure). Second, firing a timer on the main thread is totally non-deterministic with respect to anything else on the main thread. The application event loop is rather amorphously defined, so timers can fire either inside or outside the main thread's current event's undo grouping. Timers are intrinsically very unpredictable.
Aside from this 'stress' test though, I haven't (yet) got it to fall over - essentially under the conditions where only one thread (albeit one of several threads on any occasion) is making changes and saving at a time.
I'm not sure I understand this last comment. Do you have threads sharing a MOC ? Because threads with their own MOCs can make their own changes and own saves simultaneously.
- 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
