starred/CoreStore-JohnEstropia
1
0
Fork 0
mirror of https://github.com/JohnEstropia/CoreStore.git synced 2026-08-29 14:47:26 +02:00
Code Issues 95 Packages Projects Releases 10 Wiki Activity

Deadlock while using .beginAsynchronous and ListMonitor #5

New Issue
Closed
opened 2025-12-29 18:21:18 +01:00 by adam · 3 comments
adam commented 2025-12-29 18:21:18 +01:00
Owner
Copy Link
Copy Source

Originally created by @SteveKChiu on GitHub (Jul 23, 2015).

It seems CoreStore can result in deadlock with .beginAsynchronous and ListMonitor, from my experiment:

  1. call CoreStote.beginAsynchronous to insert data
  2. start CollectionView with ObjectListMonitor integration
  3. App hang upon start

If I change CoreStote.beginAsynchronous to CoreStote.beginSynchronous, then all are fine.

I trace the problem and find out:

  1. in CoreStote.beginAsynchronous, the last call is parentContext.saveSynchronously (NSManagedObjectContext+Transaction.swift: 96)
  2. in ListMonitor, the last call is try! fetchedResultsController.performFetch() (ListMonitor.swift: 505)
Originally created by @SteveKChiu on GitHub (Jul 23, 2015). It seems CoreStore can result in deadlock with .beginAsynchronous and ListMonitor, from my experiment: 1. call CoreStote.beginAsynchronous to insert data 2. start CollectionView with ObjectListMonitor integration 3. App hang upon start If I change CoreStote.beginAsynchronous to CoreStote.beginSynchronous, then all are fine. I trace the problem and find out: 1. in CoreStote.beginAsynchronous, the last call is `parentContext.saveSynchronously` (NSManagedObjectContext+Transaction.swift: 96) 2. in ListMonitor, the last call is `try! fetchedResultsController.performFetch()` (ListMonitor.swift: 505)
adam added the corestore bug label 2025-12-29 18:21:18 +01:00
adam closed this issue 2025-12-29 18:21:18 +01:00
adam commented 2025-12-29 18:21:19 +01:00
Author
Owner
Copy Link
Copy Source

@SteveKChiu commented on GitHub (Jul 23, 2015):

For develop branch, but I think it apply to main branch too.

@SteveKChiu commented on GitHub (Jul 23, 2015): For develop branch, but I think it apply to main branch too.
adam commented 2025-12-29 18:21:19 +01:00
Author
Owner
Copy Link
Copy Source

@JohnEstropia commented on GitHub (Jul 23, 2015):

@SteveKChiu This is probably a confusion caused by having two overloads for AsynchronousDataTransaction's commit() method:

public func commit(completion: (result: SaveResult) -> Void)
public func commit()

You are probably calling the commit() method which was originally named commitAndWait(). In hindsight I should have left the name as it was to indicate blocking behavior. I'll push a fix soon.

In the mean time, you can fix this on your side with either one of two ways:

  • Call CoreStore.monitorList(...) before CoreStore.beginAsynchronous(...); or,
  • Inside the closure for beginAsynchronous(...), call transaction.commit { _ in } instead of transaction.commit()
@JohnEstropia commented on GitHub (Jul 23, 2015): @SteveKChiu This is probably a confusion caused by having two overloads for `AsynchronousDataTransaction`'s `commit()` method: ``` public func commit(completion: (result: SaveResult) -> Void) public func commit() ``` You are probably calling the `commit()` method which was originally named `commitAndWait()`. In hindsight I should have left the name as it was to indicate blocking behavior. I'll push a fix soon. In the mean time, you can fix this on your side with either one of two ways: - Call `CoreStore.monitorList(...)` before `CoreStore.beginAsynchronous(...)`; or, - Inside the closure for `beginAsynchronous(...)`, call `transaction.commit { _ in }` instead of `transaction.commit()`
adam commented 2025-12-29 18:21:19 +01:00
Author
Owner
Copy Link
Copy Source

@SteveKChiu commented on GitHub (Jul 23, 2015):

I actually had tried the asynchronous one, but it still had the same problem. Anyway, I end up found a solution to the problem, please see my pull request. I am not sure if all modifications are necessary, but I think there is no reason to use the 'wait' version call in most case.

@SteveKChiu commented on GitHub (Jul 23, 2015): I actually had tried the asynchronous one, but it still had the same problem. Anyway, I end up found a solution to the problem, please see my pull request. I am not sure if all modifications are necessary, but I think there is no reason to use the 'wait' version call in most case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
abandoned
corestore bug
discussion
duplicate
enhancement
fixed
fixed
help wanted
in progress
investigating
ios/compiler bug
irreproducible
looking for workarounds
not a bug
pending
pending docs update
pull-request
Mirrored from GitHub Pull Request
 question
regression
user bug
wontfix
No labels corestore bug
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/CoreStore-JohnEstropia#5