Main thread checks again - main thread but another queue name

[hibernat]

I face to the thread checker error:

A store created on the main thread was interacted with on a non-main thread: Thread: <_NSMainThread: 0x2803f8c40>{number = 1, name = main}

The store has been created on the main thread - Queue: com.apple.main-thread
And the store is accessed from the main thread, however the queue name varies! The queue is com.apple.uikit.datasource.diffing (I use UIKit diffable datasource)

So, the thread checking should not be based on DispatchSpecificKey, as Apple uses more queues on the main thread.

I also face to another issue: When app went to background, I send an action called .applicationDidEnterBackground from the AppDelegate method. This action is not coming on the main thread, however still should be safe, as main thread cannot send anything else. (Yes, not sure whether reducer cannot still run something on the main thread, but is there any better solution?)

Any help. please?

[stephencelis]

And the store is accessed from the main thread, however the queue name varies! The queue is com.apple.uikit.datasource.diffing (I use UIKit diffable datasource)

@hibernat Sorry about that! We may not have the thread checking logic quite right yet. Can you type po Thread.current.isMainThread when you hit the UIKit data source diffing thread check breakpoint to see if that returns true?

I also face to another issue: When app went to background, I send an action called .applicationDidEnterBackground from the AppDelegate method. This action is not coming on the main thread, however still should be safe, as main thread cannot send anything else. (Yes, not sure whether reducer cannot still run something on the main thread, but is there any better solution?)

Can you throw this send in a DispatchQueue.main.sync { … }? Even though the app is being backgrounded, store access should still be done from the main thread only.

[hibernat]

@stephencelis

• For some (currently unknown) reason, po Thread.current.isMainThread is not evaluated (). However, I have no doubts that UIKit calls that from main thread.
• I cannot run DispatchQueue.main.sync { … } from applicationDidEnterBackground method, because this method already runs on the main thread (the app crashes with BUG IN CLIENT OF LIBDISPATCH: dispatch_sync called on queue already owned by current thread. This just means, that main thread checker is not working correctly when stops on A store created on the main thread was interacted with on a non-main thread: Thread: <NSThread: 0x60000063f480>{number = 18, name = (null)} Xcode Debug navigator stops on Thread 1 Queue: com.apple.main-thread (serial)

My understanding is, that UIKit always updates UI from the main thread, however this does not mean that this is updated from the same dispatch queue.

[stephencelis]

• For some (currently unknown) reason, po Thread.current.isMainThread is not evaluated (). However, I have no doubts that UIKit calls that from main thread.

Can you add a print(Thread.isMainThread) in both places then? Or try the branch opened at #823 and see if that fixes things for you?

[hibernat]

@stephencelis Thanks for your time spent on this!!!
I used the branch current-thread-check Not a complete fix. :(

This method:

func applicationDidEnterBackground(_ application: UIApplication) {
...
print("applicationDidEnterBackground")
print(Thread.isMainThread)
print("applicationDidEnterBackground")
AppContext.context.chatViewStore.send(.applicationDidEnterBackground)
}

produces this:

applicationDidEnterBackground
true
applicationDidEnterBackground

Warning:

A store created on the main thread was interacted with on a non-main thread:

Thread: <NSThread: 0x6000007bc940>{number = 31, name = (null)}

An effect returned from the action "ChatAction.applicationDidEnterBackground" completed on a non-main thread. Make sure to use ".receive(on:)" on any effects that execute on background threads to receive their output on the main thread, or create this store via "Store.unchecked" to disable the main thread checker.

The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the main thread.

The issue with diffable data source seems to be fixed.

However, I have found another issue. Code:

NotificationCenter.default.publisher(for: .userSchoolIdDidChangeNotification)
.receive(on: DispatchQueue.main)
.sink { [weak self] notification in
print("userSchoolIdDidChangeNotification")
print(Thread.isMainThread)
print("userSchoolIdDidChangeNotification")
self?.chatViewStore.send(.userEnvironmentDidChange)
}
.store(in: &cancellables)
NotificationCenter.default.publisher(for: .profileIdDidChangeNotification)
.receive(on: DispatchQueue.main)
.sink { [weak self] notification in
print("profileIdDidChangeNotification")
print(Thread.isMainThread)
print("profileIdDidChangeNotification")
self?.chatViewStore.send(.userEnvironmentDidChange)
}
.store(in: &cancellables)

Results in this:

userSchoolIdDidChangeNotification
true
userSchoolIdDidChangeNotification
profileIdDidChangeNotification
true
profileIdDidChangeNotification

Warning:

A store created on the main thread was interacted with on a non-main thread:

Thread: <NSThread: 0x600002fb3580>{number = 22, name = (null)}

An effect returned from "ChatAction.userEnvironmentDidChange" emitted the action "ChatAction.getMemberships(....)" on a non-main thread. Make sure to use ".receive(on:)" on any effects that execute on background threads to receive their output on the main thread, or create this store via "Store.unchecked" to disable the main thread checker.

The "Store" class is not thread-safe, and so all interactions with an instance of "Store" (including all of its scopes and derived view stores) must be done on the main thread.

My apologies, I have to sleep (I am a couple of hours ahead of you)

[hibernat]

@stephencelis I have just double checked whether the store is created on the main thread (Thread.isMainThread). Yes, it is...

[iampatbrown]

@hibernat are you using receive(on:) for the effect returned by ChatAction.userEnvironmentDidChange

[hibernat]

@stephencelis The issue with effect ChatAction.userEnvironmentDidChange is resolved. Error on my side.

Thanks, @iampatbrown . One receive(on:) is not enough when flatMap is used...

[stephencelis]

@hibernat We just cut a new point release with the new code. Can you give it a spin and let us know if all the checks are passing for you now?

[hibernat]

@stephencelis CONGRATULATIONS! And THANK YOU!
All my issues are resolved in 0.28.1
👏

[ferologics]

Tangentially related, recently some SwiftUI animations are executed off the main thread.