Question

Currently I’m using Restkit to control all my (Core-) data in my app. I’m using it to keep in sync with the server using RKManagedObjectMapping and I use [myMyNSManagedObject createEntitity] together with [[RKObjectManager §sharedManager].objectStore save] to manually edit items within Grand Central Dispatch.

Is there any recommendation to do this in this or an other way? Because sometimes the app freezes in a deadlock executing this code of Restkit

+ (NSArray*)objectsWithFetchRequest:(NSFetchRequest*)fetchRequest {
    NSError* error = nil;
    NSArray* objects = [[self managedObjectContext] executeFetchRequest:fetchRequest error:&error];
    if (objects == nil) {
        RKLogError(@"Error: %@", [error localizedDescription]);
    }
    return objects;
}

with that

- (NSError*)save {
    NSManagedObjectContext* moc = [self managedObjectContext];
    NSError *error;
    @try {
        if (![moc save:&error]) {
            if (self.delegate != nil && [self.delegate respondsToSelector:@selector(managedObjectStore:didFailToSaveContext:error:exception:)]) {
…

in parallel. Before I switched to Restkit I put a “context performBlockAndWait” around each entity-editing code and was on the safe side with no deadlocks. I have no other NSManagedObjectContext or something created by myself, all comes from Restkit.

Answer 1

In my case, the problem was that I was passing NSManagedObjects across thread boundaries, and using them on threads other than the ones on which they were fetched from their respective NSManagedObjectContext. It was really subtle in my case, as I knew that I wasn’t supposed to do this, but did it accidentally anyways. Instead of passing the managed objects, I started passing the NSManagedObjectIDs (and then fetching from the local thread’s MOC), and haven’t encountered a deadlock since. I’d recommend you do a deep scan of your code to make sure you are only using managed objects in the threads that spawned them.