Re: CoreData and Threading
Re: CoreData and Threading
- Subject: Re: CoreData and Threading
- From: Frederic Testuz <email@hidden>
- Date: Sat, 19 Nov 2011 17:00:51 +0100
Le 19 nov. 2011 à 00:21, patrick machielse a écrit :
> 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…
If you can limit yourself to 10.7 have you look at the changes of NSManagedObjectContext. You can now have parent-child relationship between contexts. A save: on a child context will propagate to the parent context, not to the persistent store. And a fetch: on a child context is done through the context to the parent context (if I understand correctly).
I did some tests with a parent context for UI inited with NSMainQueueConcurrencyType and a child context inited with NSPrivateQueueConcurrencyType. The changes in the child context are automatically reflect in the UI after a save: on the child context.
Look at the release notes for Core Data for Lion.
--
Frédéric
_______________________________________________
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