NSPrivateQueueConcurrencyType context can only operate within performBlock?

Question

I wonder if NSPrivateQueueConcurrencyType context only operate within -performBlock and -performBlockAndWait. and NSManagedObject return from NSPrivateQueueConcurrencyType context can not accessed outside the performBlock?

I found the following sentence from apple doc "What's new in iOS 5.0"

When sending messages to a context created with a queue association, you must use the performBlock: or performBlockAndWait: method if your code is not already executing on that queue (for the main queue type) or within the scope of a performBlock... invocation (for the private queue type). Within the blocks passed to those methods, you can use the methods of NSManagedObjectContext freely.

if so, why MagicalRecord and XMPPFramework do not operate the context and NSManagedObject within the block?

Answer 1

I have no idea what the code in MagicalRecord and XMPPFramework does or does not do. You will need to contact them through their normal support means.

I can, however, tell you that if you create a MOC with NSPrivateQueueConcurrencyType, then the only way you should ever access that MOC or managed objects owned by that MOC is through the performBlock* API.

If you create a MOC with NSMainQueueConcurrencyType, then you can access it if you are running in the main thread, or via the performBlock* API.

If you create a MOC with NSConfinementConcurrencyType, then you must only access the MOC from the thread in which the MOC was created. If concurrency is not specified, Confinement is used as the default.

Those are the only current ways to create a MOC, and a summary of the rules for their use.

I believe MagicalRecord uses confinement and keeps a MOC per thread, but I have never used it, and have only looked at older versions of the code base, so it could have changed greatly with the advent of nested contexts.