# Coroutines native-mt versus normal artifacts

**URL:** <https://discuss.kotlinlang.org/t/coroutines-native-mt-versus-normal-artifacts/19153>\
**Category:** Libraries\
**Created:** [September 14, 2020, 10:48am UTC](https://discuss.kotlinlang.org/t/coroutines-native-mt-versus-normal-artifacts/19153 "2020-09-14T10:48:22Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rgoldberg](https://avatars.discourse-cdn.com/v4/letter/r/5f8ce5/32.png) [@rgoldberg](https://discuss.kotlinlang.org/u/rgoldberg)\
**Post date:** [September 14, 2020, 10:48am UTC](https://discuss.kotlinlang.org/t/coroutines-native-mt-versus-normal-artifacts/19153/1 "2020-09-14T10:48:22Z")

</div>

Where are the differences between versions `1.3.9` & `1.3.9-native-mt` documented for the coroutine libraries?

e.g.: `org.jetbrains.kotlinx:kotlinx-coroutines-core`

I assume that `1.3.9-native-mt` uses native multithreading. If so, what platforms are supported? Are there any advantages to using `1.3.9` instead of `1.3.9-native-mt` for a platform that is supported by the latter?

---

<div class="post-metadata">

**Author:** ![GrahamLea](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.kotlinlang.org/grahamlea/32/8182_2.png) [@GrahamLea](https://discuss.kotlinlang.org/u/GrahamLea)\
**Post date:** [December 2, 2020, 6:16am UTC](https://discuss.kotlinlang.org/t/coroutines-native-mt-versus-normal-artifacts/19153/2 "2020-12-02T06:16:01Z")

</div>

I don’t know this topic well enough to give a succinct answer, but I think you can find the relevant information here:

[https://kotlinlang.org/docs/mobile/concurrency-and-coroutines.html#multithreaded-coroutines](https://kotlinlang.org/docs/mobile/concurrency-and-coroutines.html#multithreaded-coroutines)

and here:

> **[Kotlin/Native Memory Management Roadmap | The Kotlin Blog](https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memory-management-roadmap/)**
>
> TL;DR: The current automatic memory management implementation in Kotlin/Native has limitations when it comes to concurrency and we are working on a replacement. Existing code will continue to work and