Bei Verwendung von NSPrivateQueueConcurrencyType und NSMainQueueConcurrencyType types für NSManagedObjectContext ,
Ist es sicher, geschachtelte performBlock Aufrufe im selben Kontext zu machen?
Es mag blöd klingen, aber ich habe eine Codebase mit vielen Helfer-Methoden, die die executeFetchRequest -Aufrufe kapseln. Ich möchte keine Annahmen treffen, ob der Anrufer bereits performBlock verwendet hat oder nicht.
Zum Beispiel:
Ich habe es versucht und es funktioniert. Aber ich habe (auf die harte Tour) gelernt, sehr vorsichtig mit Core Data und Multi-Threading zu sein.
Ja, performBlockAndWait ist reentrant. Direkt von Apples Release Notes ...
Core Data formalisiert das Parallelitätsmodell für die NSManagedObjectContext Klasse mit neuen Optionen. Wenn Sie ein erstellen context können Sie das Concurrency-Muster angeben, das mit ihm verwendet werden soll: Thread Confinement, eine private Dispatch-Warteschlange oder die Hauptversendung Warteschlange. Die NSConfinementConcurrencyType-Option bietet das gleiche Verhalten, das auf Versionen von iOS vor 5.0 vorhanden war und ist Standard. Beim Senden von Nachrichten an einen Kontext, der mit einer Warteschlange erstellt wurde Assoziation müssen Sie performBlock: oder performBlockAndWait verwenden: Methode, wenn Ihr Code nicht bereits in dieser Warteschlange ausgeführt wird (für die Hauptwarteschlangentyp) oder im Rahmen eines performBlock ... Aufrufs (für den privaten Warteschlangentyp). Innerhalb der Blöcke gingen diese an Methoden können Sie die Methoden von NSManagedObjectContext frei verwenden. Das performBlockAndWait: Die Methode unterstützt die API-Reentrancy. Der performBlock: Methode enthält einen Autorelease-Pool und ruft den processPendingChanges-Methode nach Abschluss.
Tags und Links ios core-data nsmanagedobjectcontext