On Nov 22, 2010, at 07:58, Hunter Hillegas wrote: > I think someone somewhere told me that if you create a MOC on the main > thread, there's some special runloop integration that is included, hence one > of the reasons it's important to not create one on the main thread and then > pass it around.
Perhaps that's true, but it sounds like an urban myth. If it's true, the MOC locking approach can't work *at all* either -- because for the duration of the lock the MOC is in fact being used on a background thread. But the MOC locking approach *can* work, ergo ... etc ... QED. On Nov 22, 2010, at 04:34, vincent habchi wrote: >> I think maybe you have more design options here. For example, you can [in >> principle, I think] multithread with a single MOC without locks if you pass >> "ownership" of the MOC around between threads that make changes, so that >> ownership serializes access. That requires the ownership passing to be >> thread safe, and you already have [I think] the > > What do you mean exactly? Could you elaborate just a little bit? It seems feasible to design your app so that when something non-UI-related needs to happen, you can dispatch the work as a GCD-based operation. For operations that need to modify the data, it's easy to just pass the main MOC as a parameter into the GCD block, isn't it? All you need to do is ensure that only one such MOC-using block can execute at once. That's easy too, using NSOperation to limit the queue to one executing operation at a time, or using a separate one-at-a-time queue for just the operations that modify data, or using operation dependencies -- isn't it? Secondarily, you'd want each operation to be short, if your main thread might need to wait for updates to complete, for UI reasons, so you probably don't want any big enumeration loops in a single block. Maybe you also need a way of prioritizing operations, so that an operation that the main thread is waiting on can execute ahead of true background operations in the queue. Other than that there's no locking or thread synchronizing for you to code, because you're seamlessly using the locking/synchronizing that's built into the GCD and NSOperation mechanisms. In effect, Apple's done the heavy lifting for you. This sort of thing would be especially attractive if you also have big background operations that *don't* modify the data (which I think you said you do). Those operations can run fully concurrently, because they can use their own MOC. _______________________________________________ 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
