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: Luke Evans <email@hidden>
- Date: Sat, 21 Feb 2009 01:49:15 -0800
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.
_______________________________________________
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