Kotlin / multithreading nativo usando corrotinas

Tenho experimentado a multiplataforma do kotlin e é brilhante, mas me deixa perplexo. O congelamento de estado entre threads faz sentido conceitualmente e funciona bem em exemplos simples onde pequenos objetos ou primitivos são passados ​​de um lado para outro, mas em aplicativos do mundo real, não consigo contornar InvalidMutabilityException.

Pegue o seguinte snippet de código comum de um aplicativo Android

class MainViewModel(
    private val objectWhichContainsNetworking: ObjectWhichContainsNetworking
)

    private var coreroutineSupervisor = SupervisorJob()
    private var coroutineScope: CoroutineScope = CoroutineScope(Dispatchers.Main + coreroutineSupervisor)

    private fun loadResults() {
        // Here: Show loading
        coroutineScope.launch {
            try {
                val result = withContext(Dispatchers.Default) { objectWhichContainsNetworking.fetchData() }
                // Here: Hide loading and show results
            } catch (e: Exception) {
                // Here: Hide loading and show error
            }
    }
}

Nada muito complexo, mas se usado em código comum e executado a partir de Kotlin / Native, coloque InvalidMutabilityException em MainViewModel.

Parece que a razão para isso é que qualquer coisa passada comContext é congelada recursivamente, portanto, porque objectWhichContainsNetworking é uma propriedade de MainViewModel e é usado em withContext, então MainViewModel é pego no congelamento.

Minha pergunta é: isso é apenas uma limitação do modelo de memória Kotlin / Native atual? Ou talvez a versão atual das corrotinas? E há alguma maneira de contornar isso?

Nota: versão das corrotinas: 1.3.9-native-mt. kotlin versão 1.4.0.

Edição 1: Parece que o código reduzido acima realmente funciona bem. Acontece que o código incriminador era uma var atualizável no modelo de exibição (usado para manter uma referência ao último estado de exibição) que fica congelado e, em seguida, lança a exceção quando tenta ser mutado. Vou tentar usar Fluxo / Canais para garantir que não haja nenhuma referência var necessária e ver se isso corrige o problema geral.

Nota: se houver uma maneira de evitar que MainViewModel seja congelado em primeiro lugar, ainda seria fantástico!

Edição 2: substituiu a var por Flow. Não consegui obter coleta de fluxo padrão no iOS até usar os ajudantes aqui:https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/mobileMain/kotlin/org/jetbrains/kotlinconf/FlowUtils.kt.

MainViewModel ainda fica congelado, mas como todo o seu estado é imutável, não é mais um problema. Espero que ajude alguém!

Em seu código original, você está referenciando um campo do objeto pai, o que faz com que você capture todo o pai e o congele. Não é um problema com corrotinas. As corrotinas seguem as mesmas regras de todas as outras bibliotecas de simultaneidade no Kotlin / Native. Ele congela o lambda quando você cruza os fios.

class MainViewModel(
    private val objectWhichContainsNetworking: ObjectWhichContainsNetworking
)

//yada yada
    private fun loadResults() {

        coroutineScope.launch {
            try {

                val result = withContext(Dispatchers.Default) {

                    //The reference to objectWhichContainsNetworking is a field ref and captures the whole view model
                    objectWhichContainsNetworking.fetchData() 

            }

        } catch (e: Exception) {}
    }
}

Para evitar que isso aconteça:

class MainViewModel(
    private val objectWhichContainsNetworking: ObjectWhichContainsNetworking
){
    init{
        ensureNeverFrozen()
    }
    //Etc

A coisa mais complicada com o modelo de memória é isso. Se acostumando com o que está sendo capturado e evitando isso. Não é tão difícil quando você se acostuma, mas você precisa aprender o básico.

Falei longamente sobre isso:

Kotlin prático / simultaneidade nativa

Kotlin Native Concurrency Hands On

KotlinConf KN Simultaneidade

O modelo de memória está mudando, mas vai demorar um pouco antes que isso aconteça. Depois que você se acostuma com o modelo de memória, os problemas imutáveis ​​geralmente são fáceis de diagnosticar.