Closed artdfel closed 3 years ago
Can you please explain in more detail why you don't expect it to be frozen? What I see there is that you use withContext(dispatcher)
to change execution context from the main thread to another background thread and then transfer the reference to SomeClass()
back from the background thread to the main thread. It must be frozen in this case and works just like it is expected to work.
There's no change in thread. We have the outer call to runBlocking(dispatcher)
and then the inner call to withContext(dispatcher)
. So the same dispatcher in both calls and the thread is the same.
When you call runBlocking(disptacher)
you change from the main thread to the background thread. At this moment the corresponding coroutine becomes shared (frozen) and it recursively affects all its children that you launch inside of it.
Yeah, makes sense! I was trying to reproduce an issue we saw in our app where the Swift part of the app would call into Kotlin on the main thread. The Kotlin code would launch a new coroutine running on the main thread too. The value this couroutine returned later (still on the main thread) caused FreezingException which was unexpected as everything happened on the main thread.
Anyways, I cannot come up with a sample which reproduces the original issue. And we have refactored our Kotlin code and the issue doesn't happen any longer. You can close this. Thank you for your time!
According to kotlinx.coroutines Contributing Guidelines, I'm creating this issue as a mirror for KT-42898, reported by Niklas Therning.
Original issue: https://youtrack.jetbrains.com/issue/KT-42898
Description:
Kotlin Native 1.4.10 with coroutines 1.3.9-native-mt-2. Xcode 12.0.1 and iOS 14 simulator.
I have also tested this against the current HEAD (commit 1b0e196) of the
native-mt
branch with the same outcome.I would not expect the SomeClass instance in this piece of code to get frozen: