Core Data stack on serial queue results in deadlock - ios

Question

I'm trying to migrate a core data database to Realm (somewhere between 0-2 million rows), and am running into a deadlock that as far as I can tell, shouldn't be happening.
From a Singleton class, I'm launching the migration like this:
_queue = dispatch_queue_create("DiagnosticMigrationQueue", NULL);
dispatch_async(_queue, ^{
_realmMigrator = [[CoreDataToRealmMigrator alloc] init];
[_realmMigrator performMigrationToRealm];
});
Within the performMigrationToRealm method, I set up the Core Data stack thusly:
- (void) performMigrationToRealm
{
self.migrationIsRunning = YES;
NSURL *url = [[[NSFileManager defaultManager] URLsForDirectory:NSLibraryDirectory inDomains:NSUserDomainMask] lastObject];
url = [url URLByAppendingPathComponent:#"persistentStore"];
NSError *error;
NSManagedObjectModel *model = [NSManagedObjectModel mergedModelFromBundles:nil];
NSManagedObjectContext *context = [[NSManagedObjectContext alloc] initWithConcurrencyType:NSConfinementConcurrencyType];
context.persistentStoreCoordinator = [[NSPersistentStoreCoordinator alloc] initWithManagedObjectModel:model];
[context.persistentStoreCoordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"DiagnosticData"
URL:url
options:nil
error:&error];
Understanding Check: When I create the queue, none of the Core Data stack has been set up yet. Therefore, the NSManagedObjectContext is only created on whatever thread GCD decides to put my block on.
So far, so good. No problems. I now run a method that - in batches of 100,000 - grabs all the NSManagedObjectIds in the Entity. It looks something like this:
for (NSInteger numberOfMigratedBatches = 0; numberOfMigratedBatches < totalNumberOfBatches; numberOfMigratedBatches++)
{
NSArray *samples = [context executeFetchRequest:fetchRequest error:&error];
if (samples && !error)
{
[self transferWeightSamplesToRealmWithObjectIds:samples withContext:context];
}
[context reset];
fetchRequest.fetchOffset = batchSize * (numberOfMigratedBatches+1);
}
The line that goes funky is the fetchRequest in the code block above. Even though I've launched this process on a serial queue, I somehow end up with this:
Each of those minion_duties2 threads is stuck on the same line of code, namely the fetchRequest above.
What is going on here? I understand that queues != threads, and that GDC will put my code on whichever thread is sees fit. However, I wouldn't expect that it would put my code on THREE threads. Also, what is com.apple.root.user-initiated-qos.overcommit? I'll say it's overcommitted. I only want this code run one time!

Answer 1

So, this is technically not an answer to the question you posted, but, it could potentially provide you with a way that would allow you to avoid the problem you're running into (workaround?).
Since my guess is that it's the several different fetch requests trying to execute on several different threads that's causing the deadlock, I would suggest that instead of doing the batching manually, you do it by setting the fetchBatchSize property on NSFetchRequest, and let core data do it for you, and hence avoid doing multiple fetch requests altogether, if memory usage is an issue, try wrapping the innards of your for loop in an autoreleasepool block (I'm guessing there is a for loop inside the transferWeightSamplesToRealmWithObjectIds:withContext: method).
Core data has a concept called batching & faulting. From Apple documentation of NSFetchRequest:
If you set a non-zero batch size, the collection of objects returned
when the fetch is executed is broken into batches. When the fetch is
executed, the entire request is evaluated and the identities of all
matching objects recorded, but no more than batchSize objects’ data
will be fetched from the persistent store at a time. The array
returned from executing the request will be a proxy object that
transparently faults batches on demand. (In database terms, this is an
in-memory cursor.)
Hopefully, this helps you somewhat.