Why not return to the main thread after constructing a stack ?

[plm75]

It is pretty common inside a TableViewController's init or viewDidLoad method to have initialisation code like the following:

override func viewDidLoad() {
  super.viewDidLoad()
  CoreDataStack.constructSQLiteStack(withModelName: "SomeName") { outcome in
    print(NSThread.isMainThread())     // false
    switch outcome {
      case .Failure(let error)        : print(error)
      case .Success(let coreDataStack):
        self.coreDataStack = coreDataStack
        self.tableView.reloadData()    // crash
    }
  }  
}

This code will crash however because the callback is executed on a background thread (created by setupSQLiteBackedCoordinator.

Unless I missed something, it seems to me it would be less confusing if the callback was executed on the main thread. After all, once the stack has been set up why remain in the background thread?

A pretty simple fix would be to just wrap the callback calls inside constructSQLiteStack:

    dispatch_async(dispatch_get_main_queue(), { 
      callback(.Success(stack))  // or callback(.Failure(error))
    })

[rcedwards]

While in many cases you may want to work with your Stack on the main thread after setup, this is not a universal situation.

I do think we could simplify the setup by including a parameter to specify the callback queue similar to how NSURLSession's delegateQueue works. Perhaps this could default to the main queue, but I'm not sure about that yet.

[rcedwards]

@zwaldowski curious about your opinion on this one also.

[zwaldowski]

Providing a queue would be fine but I think pushing to the main thread is an API design crutch.

[rcedwards]

CoreDataStack API design crutch or app level API design crutch?

[zwaldowski]

Er, both.

[rcedwards]

Added in v1.2.4