Does anyone know why the mt version of DroidconKotlin has the `CoroutineScope` moved to a separate c...

# kotlin-native

[Thomas]

Does anyone know why the mt version of DroidconKotlin has the CoroutineScope moved to a separate class?

See the following: https://github.com/touchlab/DroidconKotlin/blob/kpg/mt_coroutines/sessionize/lib/src/commonMain/kotlin/co/touchlab/sessionize/BaseModel.kt

If you check the master branch than you can see that BaseModel just implements CoroutineScope . In the kpg/mt_coroutines branch that implementation was moved to a separate class, called MainScope. Is there a reason behind this change to support mt coroutines? Is it possible that MainScope can become frozen for some reason?

[kpgalligan]

I do!

[kpgalligan]

If it’s baked into the model, that will freeze the model. I wanted to keep the model classes main thread only, and unfrozen.

[kpgalligan]

If you look back at master, the scope was part of the model, but mt coroutines will freeze that: https://github.com/touchlab/DroidconKotlin/blob/master/sessionize/lib/src/commonMain/kotlin/co/touchlab/sessionize/BaseModel.kt

[Thomas]

Thanks for explaining, that is actually quite understandable

[Thomas]

I am trying to support mt coroutines in my project so I was looking at some examples!

[kpgalligan]

We have a cleaner example project. Not public yet, but can add you with a github account

[Thomas]

That would be great! I am having some issues with freezing/coroutines so it would be nice to have some samples to look at. My GitHub account is Thomas-Vos

[kpgalligan]

Added. Having issues with freezing state that you didn’t want to freeze?

[Thomas]

I cannot find the project anywhere, do you have a link?

[kpgalligan]

Hmm. It should have sent an invite I think? I’ll send link, though…

[kpgalligan]

https://github.com/touchlab/KaMPStarter

[Thomas]

That links shows the invitation, thanks

[Thomas]

Having issues with freezing state that you didn’t want to freeze?

Yes exactly. My view model is getting frozen (which is not supposed to happen). So I added ensureNeverFrozen() to the view model, but the stack trace doesn’t really help me a lot.

[kpgalligan]

The stack trace should point to where it’s being frozen, yes? It’s a little tough with the coroutines preview because sometimes the exception will happen inside the coroutines and the error doesn’t get reported well

[Thomas]

Here is an example

Untitled

[kpgalligan]

I’m working on an intellij plugin to tell you when you’re probably capturing and freezing state unintentionally, but that needs a little more time.

[Thomas]

That sounds very good!

[kpgalligan]

I think like ~90% of the time the problem is capturing a field on your parent class. It looks like it’ll just capture the field, but it captures the whole class.

[kpgalligan]

membercap.mp4

[kpgalligan]

That’s the plugin. It’ll make a little error if you’re trapping state on something that maybe shouldn’t be frozen.

[Thomas]

Wow that would really come in handy once it’s finished

[kpgalligan]

Soon-ish

[Thomas]

Are all Flow operators supposed to work correctly when they are frozen?

[kpgalligan]

Don’t know?

[kpgalligan]

I assume yes.

[Thomas]

I am having some issues with combine(…) but the stack trace really doesn’t help me

[Thomas]

The one I posted above

[kpgalligan]

Trapping state?

[kpgalligan]

Can you post some code?

[Thomas]

It’s a bit complicated, I’ll see if I can simplify it a bit

[Thomas]

SampleMacos_kt.kt

[Thomas]

Stack trace

[Thomas]

I don’t know why it throws the exception, do you?

[Thomas]

Also it’s just a sample, so the code does not make any sense, but as far as I know it should not throw an exception.

[kpgalligan]

What version of coroutines are you using?

[Thomas]

1.3.3-native-mt

[kpgalligan]

Just looking at that I don’t. I’d try other flow operators as well. You do need to ensure that none of your other dependencies are pulling in a different coroutines version. Can you send your build config?

[kpgalligan]

Just sourcesets and deps

[Thomas]

I used your KNConcurrenySamples on the mt_coroutines branch

[kpgalligan]

Hmm

[Thomas]

If I replace:

combine(flowOf(sd), flowOf(sd)) { a, b -> a to b }

with:

flowOf(sd)

then all works fine

[kpgalligan]

It’s very possible that there are parts of Flow that don’t work correctly on native. I’ve found little issues here and there.

[Thomas]

This code has the same issue, so I am guessing it is a bug in the combine operator.

Untitled

[Thomas]

Yes, that’s what I think too. I will report it on the native-mt pull request.