Has there been indication yet on whether `native mt` version

Question

Has there been indication yet on whether `native mt` version of kotlinx coroutines will be made available that works with Kotlin 1 4 doesn t look at least like there s one corresponding to rc release

russhwolf · Answer

Roman s blog post on the memory model changes suggested they will continue to release native mt stuff but it doesn t look like there s been any actual updates since M2 My guess is it got to be too complicated to juggle multiple lib releases during the preview period and we ll see something after the 1 4 release But no official word on anything that I m aware of

John O&apos;Reilly · Answer

Yeah hopefully the other moving part here is ktor s planned integration of `native mt` stuff

Andrea Prearo · Answer

That would be great Ktor has been a bit problematic as I tried to use the `native mt` coroutines

John O&apos;Reilly · Answer

this is last I think I saw on that <https kotlinlang slack com archives C0A974TJ9 p1591864919269100>

John O&apos;Reilly · Answer

this look encouraging <https github com Kotlin kotlinx coroutines tree native mt 1 4 rc>

russhwolf · Answer

Oh nice I missed that branch Hopefully some good news soon then

rudolf.hladik · Answer

maybe < e5l> has some insight about ktor native mt 1 4 rc support

Chris Mulder · Answer

I inferred from this reaction that native mt will be in 1 4 <https kotlinlang slack com archives C3SGXARS6 p1595275040223700 thread ts=1595265928 217900 amp cid=C3SGXARS6>

John O&apos;Reilly · Answer

John O&apos;Reilly · Answer

note you need to do something like following to avoid transitive dependencies of likes of ktor picking up non `native mt` version though of course as per above hopefully have version of ktor soon that works with `native mt` ``` implementation org jetbrains kotlinx kotlinx coroutines core $ Versions kotlinCoroutines force = true ```

russhwolf · Answer

That s always been true for working with native mt and ktor I think

John O&apos;Reilly · Answer

It s funny I definitely did have to do that at one stage but for some reason that hadn t been case for last while this is new project and is using 1 4 based structure where I only have to add dependency for `common` so not sure if that s a factor as well

John O&apos;Reilly · Answer

initial testing with this for Android and iOS looks good but getting following now for some reason for macOS client ```Undefined symbol kernelrpc mach port destroy trap```