Home/ Questions/Q 9114977
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T04:19:21+00:00

For some reason using dispatch_async and Core Data together causes my app to completely

  • 0

For some reason using dispatch_async and Core Data together causes my app to completely freeze, but not crashed.

Symptom

The user interface is not responsive. The app does not crash.

The app uses [[UIAccelermeter sharedAccelerometer] setDelegate: self] to get accelerometer values continuously. The “accelerometer:didAccelerate:” callback runs on main thread. When this issue occurs, the callback no longer executes.

Therefore the main thread appears to be “frozen”.

Context

I use NSURLConnection in my app to send HTTP requests to my server. In connectionDidFinishLoading, where response data is handled, it takes about 2 seconds to execute and the user interface would be unresponsive during those 2 seconds, because it runs in the main thread.

After some research, it seems that gcd/dispatch_async is the best solution for this situation to execute the data handling in the background. So, in connectionDidFinishLoading, I added the following gcd calls:

dispatch_queue_t queue;
queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0);
dispatch_async(queue, ^{
    [self handleTheData: connection];
});

This works fine sometimes, but it would cause app to freeze randomly – Even though same code is used, with the same data in Core Data storage, repeated tests show that symptom can be observed X% of the time. The chance of issue happening is affected by a few factors, explained further below.

What does handleTheData() do?

It examines the response data from NSURLConnection, which is JSON formatted string. The string is 3 lists of entity, and each entity is an array of array of numbers. So there are codes to convert the JSON formatted string into 3 NSMutableArray of custom object, where each object is a subclassed NSManagedObject.

During the convertion, since these ojects are “temporary” in that they may or may not get stored permanently, they are created in “nil” NSManagedObjectContext, like so:

SampleEntity *newEntity= 
(SampleEntity *) [[NSManagedObject alloc] initWithEntity:entity 
                       insertIntoManagedObjectContext:nil
               ];

This way, they will not be mixed with the main context.

Then these new objects are compared with existing entities in data store. So there are some codes to fetch from data store repeatedly to see if a particular new entity already existed, and depending on the data of the new entity, the new entity may be saved to data store, or the existing entity may be updated.

[managedObjectContext save: &error] is called often to ensure that changes are saved permanently.

Anything else running in background?

As mentioned in Symptom section, Accelerometer runs in the background in the main thread using [[UIAccelermeter sharedAccelerometer] setDelegate: self]

AudioUnits have also been set up to run in the background (on a separate “priority” thread according to Apple docs) to produce sound.

Findings on cause of issue

It was found that the chance of issue happening is affected by the following factors:

  • If some debugging code is commented out, such as NSLog(@”fetchedResult: %@”, fetchedResult), the chance of issue happening decreases (but it still occurs).
  • If accelerometer is not used, the issue almost never occur (but not 100% sure as I did a limited number of tests).
  • If accelerometer is used, the chance of issue happening is about 50/50.
  • If some of the Core Data codes such as [sampleEntity setXYZ..] is commented out, the issue almost never occurs even though accelerometer is used.

Second Issue

Also, even if the main thread is not frozen, ANOTHER ISSUE occurs. The data handling code would end half way through without throwing errors.

  • What that means is, data handling will only be partially done and there is no error thrown, and the main thread continues to run fine.
  • This second issue occurs frequently (but not always) whenever the main issue does not occur.

Interesting problem isn’t it? 🙂

Edit

  • 3/1/2013 – I previously thought that the cause of issue was iOS 6. Sorry, that was completely wrong. Modified description to reflect new findings.
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I ended up lodging a Technical Support Incident with Apple development support. I supplied them with a sample project as well, which shows the same symptom.

    After a few days, I got a reply from them which pointed me to CoreData Programming Guide, and pointed out the fact that codes ran by dispatch queues need to have their own private NSManagedObjectContext.

    https://developer.apple.com/documentation/coredata/using_core_data_in_the_background

    Once I followed the advice, issue seems to be resolved!

    • 0