Error messages about 'outside its designated queue' #14

New Issue

adam · 2025-12-29T18:21:24+01:00

adam commented

2025-12-29 18:21:24 +01:00

Originally created by @JoeMatt on GitHub (Oct 16, 2015).

My project is fairy simple at this point. I'm creating and calling my CoreStore from the main queue. As soon as I attempt to insert an object I'm seeing log messages about the wrong queue.

Here' sample code

Init code

@objc public final class CoreDataDataManagerAccessor : NSObject, DataStore {
    override init() {
        super.init()

// Added to try to really force main queue
        dispatch_async(dispatch_get_main_queue(), { () -> Void in
            print("Init data stack \(CoreDataDataManagerAccessor.cacheStack)") // Force immediate init (causae race or main thread issue?) jm read
            CoreStore.logger = MyLogger()
        })
    }

    private static let cacheStack: DataStack = {
        let dataStack = DataStack(modelName: "DataManager", bundle: NSBundle(forClass: CoreDataDataManagerAccessor.self))
        do {
            try dataStack.addInMemoryStoreAndWait(configuration: nil)
        } catch {
            ELOG("Couldn't make store:  \(error as NSError)")
            fatalError("are belong to us")
        }

        return dataStack
        }()

Code to insert object

   public func setSectionNav(entries : [SectionNavEntry])  throws {
        CoreDataDataManagerAccessor.cacheStack.beginAsynchronous { [unowned self] (transaction) -> Void in

            // Clear out previous navs
            let numberOfObjectsDeleted = transaction.deleteAll(From(ManagedSectionNavEntry))
            VLOG("Deleted \(numberOfObjectsDeleted) section nav entries")

            do {
                let newEntries = try transaction.importUniqueObjects(Into(ManagedSectionNavEntry), sourceArray: entries)
} catch { throw error }

transaction.commit()
}

If I add a breakpoint to setSectionNavEntries, I'm confirmed call is coming from main thread.
If I break on CoreDataDataManagerAccessor.cacheStack, the first initialization is called from the main thread but is broken out into a dispatch_once. According to Apple, static var's are automatically wrapped and set in dispatch_once calls. Could this be the souce of the errors? It's the same pattern used in the demo code so I assumed this is safe.

Originally created by @JoeMatt on GitHub (Oct 16, 2015). My project is fairy simple at this point. I'm creating and calling my CoreStore from the main queue. As soon as I attempt to insert an object I'm seeing log messages about the wrong queue. Here' sample code Init code ``` @objc public final class CoreDataDataManagerAccessor : NSObject, DataStore { override init() { super.init() // Added to try to really force main queue dispatch_async(dispatch_get_main_queue(), { () -> Void in print("Init data stack \(CoreDataDataManagerAccessor.cacheStack)") // Force immediate init (causae race or main thread issue?) jm read CoreStore.logger = MyLogger() }) } private static let cacheStack: DataStack = { let dataStack = DataStack(modelName: "DataManager", bundle: NSBundle(forClass: CoreDataDataManagerAccessor.self)) do { try dataStack.addInMemoryStoreAndWait(configuration: nil) } catch { ELOG("Couldn't make store: \(error as NSError)") fatalError("are belong to us") } return dataStack }() ``` Code to insert object ``` public func setSectionNav(entries : [SectionNavEntry]) throws { CoreDataDataManagerAccessor.cacheStack.beginAsynchronous { [unowned self] (transaction) -> Void in // Clear out previous navs let numberOfObjectsDeleted = transaction.deleteAll(From(ManagedSectionNavEntry)) VLOG("Deleted \(numberOfObjectsDeleted) section nav entries") do { let newEntries = try transaction.importUniqueObjects(Into(ManagedSectionNavEntry), sourceArray: entries) } catch { throw error } transaction.commit() } ``` If I add a breakpoint to setSectionNavEntries, I'm confirmed call is coming from main thread. If I break on CoreDataDataManagerAccessor.cacheStack, the first initialization is called from the main thread but is broken out into a dispatch_once. According to Apple, static var's are automatically wrapped and set in dispatch_once calls. Could this be the souce of the errors? It's the same pattern used in the demo code so I assumed this is safe.

adam closed this issue

2025-12-29 18:21:24 +01:00

adam commented

2025-12-29 18:21:25 +01:00

@JoeMatt commented on GitHub (Oct 16, 2015):

I just realized the assert messages are meant to be used in conjunction with the result of condition. My mistake. Sometimes writing out an error report makes you catch your own mistake.

@JoeMatt commented on GitHub (Oct 16, 2015): I just realized the assert messages are meant to be used in conjunction with the result of condition. My mistake. Sometimes writing out an error report makes you catch your own mistake.

Sign in to join this conversation.

Branches Tags

develop

master

prototype/concurrency

minIOS13

prototype/containers

transactionSourceTracking

prototype/swiftui

minIOS11

swift5_3

prototype/propertyWrapperFields

prototype/propertyWrappers

prototype/propertyWrapper

Swift5

throwables

prototype/Swift_4_1

prototype/Swift_4_0

prototype/Swift_3_2

prototype/queryBuilders

temp/develop

corestore4_develop

prototype/mainContextToPSC

master_ios_7_to_9

swift_2_3

gh-pages

_corespotlight-test

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/CoreStore-JohnEstropia#14