Thanks for the note.
OK, that's too bad. I was suckered into thinking that following a
locking regime (one of the suggested "how to use Core Data in a
multithreaded environment" approaches) would allow things to work
satisfactorily and provide the freedom to mutate the model on any
thread so long as MOC level locking was done diligently.
I have to say that I was surprised to find that simply asking
executing a fetch request caused the MOC to hijack my call and go off
to write to controllers, but I suppose that has to happen in order to
ensure the correctness of my result (in case there are pending changes
in the controller - though wouldn't that be a _read_? No matter).
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.
Certainly, this new discovery makes a mockery (MOCkery?) of the any
locking scheme you might imagine on the context in order to have
multiple thread safely interact with the model (... unless perhaps you
are not using Cocoa features like binding).
Well, back to the drawing board...
On 20-Feb-09, at 2:09 PM, Clark S. Cox III wrote:
There aren't enough locks in the world to make it safe to update a
table's bound model on a background thread. If you have a UI element
bound to a another object, that object must never send KVO
notifications on a bacgeohnd thread.
Sent from my iPhone
On Feb 20, 2009, at 11:57, Luke Evans <l...@eversosoft.com> wrote:
Hi list,
I have a nasty deadlock caused by the condition lock used by -
[NSViewHierarachyLock _lockForWriting:handler:] never getting
acquired on a non-main thread. This is on 10.5.6 BTW.
_______________________________________________
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
