[pifflesnort]

This requires performing all mutation on dedicated code paths. If you require non-asynchronous completion, you have to use the 'wait' variant, but this introduces deadlock risk between threads.

This in turn litters your code with Core Data isms, and means that one can not simply make use of their model as a standard in-memory model.

Compare to SQLite, where one can simply open and commit a transaction synchronously on any thread.

[seivan]

Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc?

And yes, you can still not use a persistent store manage context on multiple queues.

Please stop using the word thread and use the word queue :)

[pifflesnort]

> Litters the code with Core Data ism? The same your code is littered with UIVism, NSFoundationsm and etc?

The difference is that the 'model' is what binds all of your code together. The constraints of Core Data therefor introduce tightly bound constraints on all your code.

> Please stop using the word thread and use the word queue :)

Why? Queues are M:N mapped to threads, so they are still threads. Additionally, not all work is always done on queues, especially when working with legacy APIs.