Regarding MP, there is this PR going on: <https://...
# koin
g
Regarding MP, there is this PR going on: https://github.com/InsertKoinIO/koin/pull/519
k
Interesting. “All Tests in koin-core are now working with kotlin native:” Will check that out. I did get a version of 2.0 some months ago successfully running tests on native, but there’s a lot to do with regards to state and threads.
a
very nice progress
sorry have to find time to read all of this 🙂
will read this in the weekend 😄
k
Cool. Just going to throw out some thoughts. State and how it’s handled in native should maybe be discussed. I updated the coffee maker sample to work with native style state here: https://github.com/touchlab/koin/blob/857836033d329bafa24ed952986bfd8ea78fda39/koin-projects/examples/coffee-maker/src/commonMain/kotlin/org/koin/example/ElectricHeater.kt#L4-L3
Everything that can be shared between threads, and right now that’s everything that’s kept around, needs to be frozen, so it’s internal state is
private var heating = AtomicBoolean(false)
instead of just a
Boolean
(it should be
val
instead of
var
. Just noticed)
koin-test
was split so mockito could live in it’s own Java-only module,
koin-test-mockito
Still need to deal with closing mutex for Scope
a
interesting
k
All state will be up in the air if “relaxed mode” for native is released, but that’s a while off and not complete
For those not familiar with native, “relaxed mode” is basically what we’re all used to. Mutable state. “strict mode”, which is what all current native is, is thread confined. So, if state is mutable, it’s only visible to one thread. Otherwise it’s frozen. Sounds complicated, but you get used to it. Some reading: https://medium.com/@kpgalligan/kotlin-native-stranger-threads-ep-1-1ccccdfe0c99 and https://medium.com/@kpgalligan/kotlin-native-stranger-threads-ep-2-208523d63c8f
a
thanks for the links 👍
k
The big question. Should native koin only “live” in the main thread, in which case we could roll back all the freeze stuff, or should you be able to inject from other threads? I lean towards “all threads”, so it’s not super different on native than JVM (doesn’t matter on JS), but that obviously impacts state (which will be impacted anyway, in theory, if your app is using from multiple threads). Alternatively, the more complex solution it to give an option on config, or the more dramatic change, forcing all platforms to interact on the main thread (which makes some sense but is probably a nightmare). Anyway, to discuss.
a
yeah good question
j
@kpgalligan hi! I saw that version 2.1.6-mp was published on maven-central but I did not find a corresponding commit on https://github.com/touchlab/koin I wanted to make a pull request to target Kotlin 1.3.50 - should I do it against kpg/mp-publish?
a
Hey @kpgalligan , perhaps we can release a 3.0.0 alpha with the current branch, just to help test
didn’t had time to investigate on perfs issues
k
2.1.6 was me poking around with
threadLocal
. Was going to add it to the Droidcon app, but ran out of time. I think it would be good if I pulled back
threadLocal
and made sure none of my publish edits are in there. I had a separate branch for my publish config, but that got mixed into the 2.1.6 branch. Best branch to work from now is
kpg/mp_test
, https://github.com/touchlab/koin/tree/kpg/mp_test. I just pushed the 2.1.6 branch for reference, which is https://github.com/touchlab/koin/tree/mp_threadlocal
I can resurface that this week, clean it up and have something to look over. Just need to refresh on where things were at.
j
alright, thanks - I worked from there and updating Kotlin to 1.3.50 didn't result in problems fwiw
@kpgalligan I checked out the mp_threadlocal branch - upon trying threadLocal { ... } in multiplatform environment I'm receiving a null pointer at
ThreadLocalDelegate.getValue
when running it on iOS:
Copy code
val module = module {
     threadLocal { ApiStateHandler(coroutineLaunchMode, ApiState()) }
}
val koinApplication = startKoin {
    modules(handlerModule)
}
val app: ApiStateHandler = koinApplication.koin.get()
am I using it wrong?
when I understand it correctly, the KoinApplication and its modules are frozen so I wouldn't be able change any state inside the injected classes?
k
Thread local was coded but not used. Highly possible it’s not going to work correctly. I’ve been super focused on another library for the last few weeks.
For non thread-local, all state will be frozen. You can only change state that’s in an atomic reference.