Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
- Subject: Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock).
- From: Michael Ash <email@hidden>
- Date: Sun, 22 Feb 2009 08:22:22 -0500
On Sat, Feb 21, 2009 at 9:34 PM, Ken Ferry <email@hidden> wrote:
>
>
> On Sat, Feb 21, 2009 at 4:25 PM, Michael Ash <email@hidden> wrote:
>>
>> On Fri, Feb 20, 2009 at 6:25 PM, Luke Evans <email@hidden> wrote:
>> > The more I'm getting to know Cocoa (we're still not intimate), the more
>> > it
>> > seems that regular apps with UI making use of features like Core Data
>> > etc.
>> > need to be architected very centrally around the main thread - it's only
>> > easy/safe to use background threads for activities that perform discrete
>> > processing and post their results back to some agent waiting back on the
>> > main thread.
>>
>> Cocoa is just fine with doing lots of stuff on background threads.
>> What's not fine is doing any UI stuff on background threads.
>> Practically speaking, it means that in such a multithreaded app, when
>> you do your MVC design, the view side must be done only from the main
>> thread. The model can run on any thread (assuming a proper
>> multithreaded design there), and then your controller layer needs to
>> mediate between the two to ensure that when the UI changes the model
>> the proper synchronization is performed, and that when the model
>> performs an update that needs to be reflected in the UI, all such
>> updates are shipped back to the main thread before hitting the UI.
>>
>> The trouble you're having here is not with Cocoa, but with Cocoa
>> bindings. Bindings fit into the controller layer of MVC and have
>> absolutely *no* awareness of multithreading whatsoever. If you want to
>> multithread your model, you either need to abandon bindings (my
>> favored course of action) or bind to a layer of your model which is
>> main-thread-only, and which serves as a proxy to the multithreaded
>> section.
>
> ..which isn't so hard with CoreData, because the objects aren't shared
> between threads anyway. The UI is bound to objects in a context opened on
> the main thread. Other contexts may be opened on other threads, modified,
> and committed. When the context opened on the main thread picks up the
> changes, the UI updates.
The objects are shared between threads if you're sharing them between
threads like Luke was. Of course you shouldn't do this, for the
reasons outlined in the CoreData threading documents, but that's what
he was doing.
Mike
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden