Re: Threads and Core Data, bindings results in view corruption
Re: Threads and Core Data, bindings results in view corruption
- Subject: Re: Threads and Core Data, bindings results in view corruption
- From: David <email@hidden>
- Date: Mon, 31 Mar 2008 13:49:26 -0400
Thank you very much for the response which is chock full of helpful
information. Its taken me some time to try and digest.I must admit being a
little demoralized. I've always considered threading to go hand and hand
with GUI programming. I'm having trouble envisioning the scenarios where
bindings and core data are intended to be used without threads.
I'm relatively new to Cocoa. From my previous work in win32 and Java this is
the normal scenario, not an unusual one. Can someone point me to some sample
code that illustrates how to have a worker thread updating data which is
displayed in the UI?
In my case I am/was trying to maintain a outline view representing files,
storing each node in core data. Based on these responses I'm not sure what
technologies I should reasonably be using. Is this too fine grained for Core
Data? Should I give up on bindings? Should I give up on NSTreeController?
If I try to maintain multiple MOCs, that means I have to save to get it to
show up in the other moc, right? The save as binary file can take 15 seconds
in my case when I have thousands of nodes. That hangs the UI longer than
adding the nodes to start with. Should I try to use a in memory persistent
store or will that still be slow or cause an excessive memory penalty?
Additional comments below:
On Sun, Mar 30, 2008 at 9:50 PM, Ben Trumbull <email@hidden> wrote:
>
> If you want multi-threaded work with the view and controller classes
> in Cocoa, you'll need to perform your background operations, and
> communicate back to the main thread (view & controllers) via the run
> loop. -performSelectorOnMainThread and its friends in NSThread.h are
> your best bet.
>
> Using a run loop on a background thread and communicating from the
> main thread to it with the new 10.5 -performSelector... methods is
> often conceptually simpler (easier to debug) than many other
> threading patterns.
>
> Sharing a MOC with Cocoa Bindings and a background thread will end in
> tears. Cocoa Bindings doesn't lock its bound MOC, so you're
> basically SOL.
Can I ask why don't bindings lock the bound MOC or provide the option to? I
had assumed (incorrectly) that bindings would handle threads OR provide some
means to control or configure its threading behavior.
>
> Even if it did work, though, it'd be a bad idea. Sharing a MOC means
> a background thread would still at times block the main thread and
> SPOB your app.
Why doesn't core data support locking at a finer grain? Or to rephrase, it
would be very helpful if Core Data could lock at a ManagedObject level. I
expected there to be a locking or transaction mode where I can lock it while
I fill in an object. Nothing else should require me to worry about core data
getting corrupted with multiple threads.
>
>
> These 3 points (can't work, doesn't work, shouldn't work) are why the
> Core Data Programming Guide says don't do this.
>
The Core Data programming guide in the threading section guidelines states:
"3) Pass managed objects or managed object contexts between threads.
This approach is strongly discouraged. You must ensure that you apply locks
as appropriate and necessary."
I have interpreted that to mean that locking the managedObjectContext would
be sufficient. I hadn't realized that bindings would try to obtain locks.
>
>
> The list archives also have these, which you should read:
> <http://lists.apple.com/archives/cocoa-dev/2007/May/msg00222.html>
> <http://lists.apple.com/archives/cocoa-dev/2008/Jan/msg01889.html>
>
> It's possible to shuttle pending changes between threads by hand using
> KVC.
Are you describing in general or specifically with Core Data? Can you give
more insight on this? Are you saying that I manually track changes from core
data?
If its my own objects, I would expect to manage fine grain locks or
synchronize code which modifies by object tree.
>
>
>
> If you're inserting a large number of new objects, you really should
> just batch the operation together, save, and present the user with
> new objects in the tree view in batches.
>
> On Leopard, in the scenarios under which you can save, you can also
> use -mergeChangesFromContextDidSaveNotification:
But isn't a notification received on the same thread on which it was
posted?
>
>
>
> Finally, in 4 years no one has filed a bug about this.
File a bug about what? Do you consider the threading behavior in bindings
and Core data to be a bug?
>
>
> --
>
> -Ben
>
_______________________________________________
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