Quincey: > I think the point is that it's far *less* complex because the code to deal > with a second MOC should be a lot simpler than the thread locking code. Plus, > the chances are that your locking code is wrong. :) (Trust me, that's not a > dig at you personally. But multithreading interlocks are *hard*. Such code > can work almost all of the time and still be wrong.)
Oh, I know that too ;) Back when I was in U. I worked on a custom 4 x MC68000 machine, with TAS semaphores in assembler. That was fun, hardware AND software (rewriting code is fairly free, but burning PALs was not! ;)) > You've added important information. If you're *changing* the objects > enumerated in the background thread, you're going to run into difficulties > with the NSDocument metaphor. (You can't -[save:] the MOC in the background > thread because […] No, fortunately, that's the contrary: I'm reading objects in the background, to get them displayed, while the user can modify their properties in the foreground, so only the main thread alters the relationship entity members. Besides, the background processes are transitory (only -displayInContext: in GCD queues). I try to keep it short here, but if you desire more info, I'll happily send it to you in a separate mail. Thanks again (I'm going to bed this time)! Vincent _______________________________________________ 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
