I'm struggling a bit with multi-threading approaches for CoreData…
I need to _continuously_ merge changes made in the _main_ thread into a context
held by a background thread. Most (all?) discussions about multi-threading in
CoreData discuss merging changes from a _finite_ operation in the _background_,
a quite different situation.
Situation:
----------
My application stores an object graph in CoreData using a persistent document.
The objects are manipulated by the user in the UI. Meanwhile a background
thread processes the object graph continuously to generate output.
Changes made by the user should be picked up and accounted for by the
background thread in a timely manner.
I've adopted 'thread confinement' as prescribed by Apple: the main thread and
the background thread eacht have separate contexts sharing a single persistent
store.
Options:
--------
There are two ways to receive updates on the background thread:
1 - Through 'NSManagedObjectContextDidSaveNotification' and subsequent change
merging.
However, I'd have to save the document every time the user changes the
document. This would not be a good user experience, to say the least.
2 - Through 'NSManagedObjectContextObjectsDidChangeNotification'
The objectIDs of the changed / inserted / deleted objects can be collected from
this notification and forwarded to the background thread. According to Apple:
"You pass the object IDs to thread A [-- my background thread --] by
sending a suitable message to an object on thread A. Upon receipt, on thread A
you can refetch the corresponding managed objects."
Here is where I miss information: The context of my background context isn't
aware of the changes in the main thread context (there was no merge) and
'refetch the corresponding managed objects' won't work because the shared
persistent store wasn't updated (there was no save operation from the main
context)...
At the moment I cannot find an acceptable way to merge changes from the main
thread into the background thread context. Is there a solution for my use case?
I could probably try to extend a solution with locking, but it will be error
prone…
Thanks,
patrick
--
Patrick Machielse
Hieper Software
http://www.hieper.nl
i...@hieper.nl
_______________________________________________
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
