Keep managedObjectContextDidUnregisterObjectsWithIDs: from blocking main thread

2
votes

I have an app that performs background fetches to populate entities on a map. The fetch predicate is constantly updating as the user pans and zooms on the map or changes the search filter criteria. The queries take anywhere from a fraction of a second to several seconds to complete. In order to maintain a responsive user experience, I'm performing the fetches on the parent context on a private queue using the built-in main and parent contexts of UIManagedDocument.

I was experiencing blocking on the main thread when things attempted to access the main context, which required accessing the parent context in order to reach the persistent store to fetch faults, etc. I remedied all the affected parts of my own code by pre-fetching relationships and resolving faults before allowing further background fetches on the parent context.

But I am still experiencing blocking of the UI on occasion. When I pause the app during these moments of the UI being unresponsive, I get the following stack traces on the main and private queue threads:

Thread 1Queue : com.apple.main-thread (serial)
#0  0x36a29568 in semaphore_wait_trap ()
#1  0x36ab4558 in _os_semaphore_wait ()
#2  0x0098ff0a in _dispatch_barrier_sync_f_slow ()
#3  0x28a4060c in _perform ()
#4  0x28a4d74e in -[NSManagedObjectContext(_NestedContextSupport) managedObjectContextDidUnregisterObjectsWithIDs:] ()
#5  0x289dc7ae in -[_PFManagedObjectReferenceQueue _processReferenceQueue:] ()
#6  0x289dc012 in _performRunLoopAction ()
#7  0x28c7f624 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#8  0x28c7cd08 in __CFRunLoopDoObservers ()
#9  0x28c7d10a in __CFRunLoopRun ()
#10 0x28bca980 in CFRunLoopRunSpecific ()
#11 0x28bca792 in CFRunLoopRunInMode ()
#12 0x2ff7c050 in GSEventRunModal ()
#13 0x2c1bc980 in UIApplicationMain ()
#14 0x0009a070 in main at main.m:17

Thread 288Queue : NSPersistentStoreCoordinator 0x176425c0 (serial)
#0  0x36ab71f8 in _platform_memmove$VARIANT$CortexA9 ()
#1  0x3670ab5e in ___lldb_unnamed_function194$$libsqlite3.dylib ()
#2  0x3670bd4e in ___lldb_unnamed_function195$$libsqlite3.dylib ()
#3  0x366f4cc8 in ___lldb_unnamed_function124$$libsqlite3.dylib ()
#4  0x366f23b4 in sqlite3_step ()
#5  0x289ba75c in _execute ()
#6  0x289ba454 in -[NSSQLiteConnection execute] ()
#7  0x289c77f4 in -[NSSQLCore _newRowsForFetchPlan:selectedBy:withArgument:] ()
#8  0x289c15e0 in -[NSSQLCore newRowsForFetchPlan:] ()
#9  0x289c0bd8 in -[NSSQLCore objectsForFetchRequest:inContext:] ()
#10 0x289c0564 in -[NSSQLCore executeRequest:withContext:error:] ()
#11 0x28a6ce98 in __65-[NSPersistentStoreCoordinator executeRequest:withContext:error:]_block_invoke ()
#12 0x28a7411e in gutsOfBlockToNSPersistentStoreCoordinatorPerform ()
#13 0x009889b6 in _dispatch_client_callout ()
#14 0x009901d8 in _dispatch_barrier_sync_f_invoke ()
#15 0x28a67c8e in _perform ()
#16 0x289c01de in -[NSPersistentStoreCoordinator executeRequest:withContext:error:] ()
#17 0x289bee92 in -[NSManagedObjectContext executeFetchRequest:error:] ()
#18 0x000d7f8c in __35-[MainViewController scheduleFetch]_block_invoke at MainViewController.m:1395
#19 0x28a45120 in developerSubmittedBlockToNSManagedObjectContextPerform ()
#20 0x00990e1c in _dispatch_queue_drain ()
#21 0x0098b2f4 in _dispatch_queue_invoke ()
#22 0x00992558 in _dispatch_root_queue_drain ()
#23 0x00993880 in _dispatch_worker_thread3 ()
#24 0x36ab9e24 in _pthread_wqthread ()
Enqueued from com.apple.main-thread (Thread 1)Queue : com.apple.main-thread (serial)
#0  0x0098f852 in _dispatch_barrier_async_f ()
#1  0x0098abd2 in dispatch_async_f ()
#2  0x000d7db4 in -[MainViewController scheduleFetch] at MainViewController.m:1391
#3  0x000d7086 in -[MainViewController setCurrentFetch:] at MainViewController.m:1331
#4  0x000d884a in __35-[MainViewController scheduleFetch]_block_invoke_2 at MainViewController.m:1443
#5  0x009889ca in _dispatch_call_block_and_release ()
#6  0x009889b6 in _dispatch_client_callout ()
#7  0x0098c410 in _dispatch_main_queue_callback_4CF ()
#8  0x28c7ec40 in __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ()
#9  0x28c7d360 in __CFRunLoopRun ()
#10 0x28bca980 in CFRunLoopRunSpecific ()
#11 0x28bca792 in CFRunLoopRunInMode ()
#12 0x2ff7c050 in GSEventRunModal ()
#13 0x2c1bc980 in UIApplicationMain ()
#14 0x0009a070 in main at main.m:17
#15 0x36977aae in start ()

As you can see, the private queue is busy executing a fetch on the persistent store in sqlite. But the main thread has blocked because [_PFManagedObjectReferenceQueue _processReferenceQueue:] called [NSManagedObjectContext(_NestedContextSupport) managedObjectContextDidUnregisterObjectsWithIDs:], which blocked on a semaphore waiting to access the managed object context I'm assuming. I didn't call this code, but I'd like to know how to avoid it being called and blocking the main thread.

With each new set of NSManagedObjects returned by a query on the background thread, I fetch the objects on the main thread, relative to the main context. Then I place them on the map, first removing the old entities. Once I've done this, I allow the background thread to perform another fetch if one has been queued up from further action by the user.

It seems by the name of the method managedObjectContextDidUnregisterObjectsWithIDs:, this code has something to do with unregistering the entities that I just removed from the map, removing them from memory. Since this must be happening after a new background fetch has begun, is there a way I can expedite this occurring, to delay a new fetch until it does? Or is there a way to prevent it from blocking the main thread when it does happen?

1
iosobjective-cmultithreadingcore-data
You say: "fetch predicate is constantly updating". So there could be pending fetches (nicely processed in background thread) due to user action "queued-up" in the main thread queue? If yes: "constantly updating" might not be so valuable if only the fetch results caused by the last user interaction is interesting for the user. - user3845832
It's designed to have a queue depth of one fetch, which is constantly updated with any new fetches when and if the user changes anything up until the current fetch completes and the new fetch begins. Data is displayed on the map from the last completed fetch while new data is being fetched. Once a fetch completes and the data updated on the map, the last requested fetch is executed immediately. Any time the fetch changes, the user is no longer interested in the fetch it preempts in the queue. This architecture works well other than the blocking of the UI described in my question. - Jeff Lockhart
I see: concurrent fetches are not possible. You say: "I allow the background thread to perform another fetch", so it is possible that you don't allow user producing new predicates by "panning and zooming" - or the resulting predicates will be rejected :) ? I assume this does not cause the blocking (?!) but one option could be give incremental feedback (you can see kind of objc code here: link). Those queries that "take [...] several seconds" - i would divide them to get smaller sets of interim results. - user3845832
@MarkusSchmid I don't know that I understand you quite clearly. Every time the user pans or zooms or changes a filter value, the fetch predicate is saved to a nextFetch property. If there is no current fetch, nextFetch executes immediately. When current fetch completes, nextFetch executes as soon as it can at that point, after the results of the last fetch are fetched on the main thread. There is only ever one fetch saved as nextFetch. Every time the user makes a change, the next fetch is updated to reflect it, preempting the previously queued next fetch - Jeff Lockhart
The blocking is caused by managedObjectContextDidUnregisterObjectsWithIDs: being called on the main thread while a fetch is occurring on the background thread. It's not related to the length of time the background fetch takes. There's no way to change this. It has to perform the filter operation to get the data requested. It can't be broken into smaller sets. The answer lies in not having managedObjectContextDidUnregisterObjectsWithIDs: called while the fetch is occurring. It can be called either before or after, but since I'm not calling it directly, I need to know how to control it. - Jeff Lockhart

1 Answers

0
votes

If you are deploying for iOS8, you can take advantage of the new asynchronous fetch API. See the WWDC 2014 talk on Core Data for details.

For details on managedObjectContextDidUnregisterObjectsWithIDs see the documentation for NSIncrementalStore.

If you have to target older versions of iOS, I would suggest abandoning UIManagedDocument, and using MOCs in their raw form.

However, you have to understand that any time you want to access the exact same resource at the same time, there are limitations to what you can do.

In this case, you have a parent context, being busy doing IO, and the child context needs some work done... more importantly, it needs to coordinate with its parent context to do so. This causes your delay.

Without having more information on exactly what you are doing, I can suggest a few alternatives. First, use independent contexts. If you use case requires it, you can also use multiple Core data stacks, including multiple persistent store coordinators.

For high performance tasks, I have had success using a reader stack and a writer stack, with their own complete core data stack, including PSC.