Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock). [POST SAD REALISATION]
Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock). [POST SAD REALISATION]
- Subject: Re: Surprising entanglement of UI lock during fetch request in background thread (NSViewHierarchyLock/MOC locking deadlock). [POST SAD REALISATION]
- From: Corbin Dunn <email@hidden>
- Date: Mon, 23 Feb 2009 09:20:41 -0800
On Feb 21, 2009, at 1:49 AM, Luke Evans wrote:
Well, for now we're moving to a main-thread only model for Core Data
access (I've created a little 'inter-thread thunk' toolkit for
invoking the previously offending MOC-mutating methods on the main
thread).
I'm still curious about how the "MOC-per-thread, shared coordinator"
approach works out in practice. Could anybody point me at a sample
somewhere?
Do the several MOCs synchronise themselves in this scenario, so that
new objects created in one MOC appear shortly afterward in another
(and more to the point auto-update bound controllers etc.)?
Are the latencies involved in such auto-updating (if it exists)
pretty low?
Where do "per thread" instance of MOCs typically reside and how are
they looked-up? I could imagine storing a reference in the NSThread
dictionary, but wonder if there is a lot of overhead in accessing
that.
Please log bugs requesting what you want to work, and/or the
documentation to be increased. If you have a simple test case please
also add it to the bug, as that greatly speeds up things.
thanks,
corbin
_______________________________________________
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