Hey there <@UHAJKUSTU> Have you put any thoughts i...

# decompose

[s3rius]

Hey there @Arkadii Ivanov
Have you put any thoughts into how 2.0.0's main thread checker ought to work with coroutine-test's setMain?

I use Dispatchers.setMain(StandardTestDispatcher()) in most of my tests, and this unsurprisingly triggers the MainThreadChecker.
I'm working around it with a custom implementation:

class TestMainThreadChecker : MainThreadChecker {
    override fun isMainThread(): Boolean = Thread.currentThread().threadGroup.name.contains("main")
}

But aside from the fact that I'm not even sure this is correct, it sounds like a fairly annoying hurdle for adopters of Decompose.

[Arkadii Ivanov]

Thanks for the info! That shouldn't be a crash, just an error log. So you can pretty much ignore it. Also, you should be able to disable the check by overriding the error handler. MainThreadChecker is an internal API, it shouldn't be used outside of the library.

[Arkadii Ivanov]

Would you prefer the check to be opt-in rather than opt-out?

[Arkadii Ivanov]

Also, I could add a dedicated API to disable main thread checks all together. So you could disable it in @BeforeTest.

[s3rius]

Oh geez, I saw the stacktrace and immediately jumped to the conclusion it was the reason my tests were failing. You're right, it's just a log message! 🙄

Regarding its behavior... I like that it's opt-out for production code. Particularly since it's fairly easy to "slip" onto a non-UI thread in a coroutine world. For test scenarios such as mine I don't know. In theory I'd like to retain the thread check. I assume StandardTestDispatcher is still backed by only one thread, meaning the semantics stay the same. But in practice I don't know if this would work as expected.