Batchsize and child context bug?

[jessesquires]

http://stackoverflow.com/questions/11365589/batch-size-does-not-work-when-using-parent-child-contexts

[patoroco]

I was experimenting that yesterday as I tweeted, but I'm not sure how to proceed.

There are several posts disappointing about to user parent context as CoreData "mantra", but really there looks very useful and easy to implement on apps, so I want to find a way to use it correctly.
Anyway, I think that JSQCoreDataKit could to provee a way to choose between use or not parent contexts, so I started a small proof of concept from your lib.

On the one hand, it's possible (I did it in my local and it runs well) to remove parental relationship in:
https://github.com/jessesquires/JSQCoreDataKit/blob/develop/Source/CoreDataStackFactory.swift#L102
https://github.com/jessesquires/JSQCoreDataKit/blob/develop/Source/CoreDataStackFactory.swift#L138

The problem is that after do that, it's needed to sync both context using old-NSNotificationCenter way, and I spend some time trying to do it yesterday night but I didn't finish.

Do you think that this is the way or suggest another?

UPDATE: there are a god sample of the bug with Core Data --> https://github.com/jleandroperez/FRCDeadlock

[jessesquires]

Thanks so much for the investigation @patoroco ! 😄

I'll look into this more soon.

[wiedem]

UPDATE: there are a god sample of the bug with Core Data --> https://github.com/jleandroperez/FRCDeadlock

The link you're referring to doesn't describe a bug but a limitation regarding Core Data and concurrency. I'm not sure if your link has anything to do with what @jessesquires describes.

There's one very important thing you have to keep in mind:
even if you use performBlock or performBlockAndWait, those operations are not inherently thread safe! If two managed object contexts share the same persistent store coordinator then deadlocks can very easily occur. The reason is the way persistent store coordinators work:

Coordinators do the opposite of providing for concurrency—they serialize operations.

In other words, managed object contexts need to lock their psc for certain operations.
So let's say you've got two contexts with the same psc, one bound to the main queue (1) and one to a concurrent queue (2). You call performBlock on (2) causing a lock on the psc, before this block ends you make another call through (1) on the main queue. The main queue (thread) now waits for the lock to be freed by (2) in order to make the call for (1).
Any synchronous call to the main thread inside the closure of (2) will now cause a deadlock. That's exactly what jleandroperez is doing in his demo.

A general rule of thumb: never make a synchronous call to the main queue inside a performBlock or performBlockAndWait.

[jessesquires]

Thanks @wiedem ! 👍 🎉 😄

I agree, it's easy to setup trivial situations that will cause a deadlock.

From @patoroco's original comment:

On the one hand, it's possible (I did it in my local and it runs well) to remove parental relationship...

Given this and the completion of #60, I'm going to close this as resolved. ☺️

If anyone disagrees, let me know!