<@U3SK5B492> Will the Kotlinx.coroutines library b...

# kotlin-native

[spierce7]

@olonho Will the Kotlinx.coroutines library be able to be ported to Kotlin/native without changing it's API? I'm wondering if the memory model for kotlin/native is making the port more difficult than expected.

[gildor]

API already different on JS, just because you have only 1 thread there, so some things impossible to implement or implemented preserving JVM semantics (like runBlocking)

[spierce7]

I'm aware of runBlocking not being part of the common library, that's not really an API change though.

I'm wondering if kotlin/native might require more drastic change as a lambda could potentially capture all parent state:

var parentState = 42

val intendedSharedState = 42
launch {
  // I have unsafe access to parentState here
}

[gildor]

I suppose launch will run on the same thread, so why not?

[gildor]

But I may be wrong, of course

[svyatoslav.scherbina]

Memory model indeed affects porting kotlinx.coroutines to Native.
But we are working on evolving our memory model to answer those and other issues.
Our current vision is that lambda in launch {} can capture only shared state (e.g. frozen objects).
In the example above lambda captures mutable state and thus this code will throw an exception.

[spierce7]

@svyatoslav.scherbina When will we be able to try out this memory model?

[svyatoslav.scherbina]

@spierce7 We have no ETA currently.