With the Kotlin Native documentation there is an article that isn't applicable to all Kotlin Native targets: https://kotlinlang.org/docs/multiplatform-mobile-concurrency-overview.html This article (is iOS/mobile specific) should be moved somewhere else. Also the article's title should be renamed to Multiplatform Mobile Concurrency Overview.

Personally I find it applicable to all K/N targets, it describes the memory model in general. Do you see any particular targets that this article is not applicable to?

The Linux targets work differently with their concurrency from other targets like the iOS ones for example.

I believe from the concurrency perspective all K/N targets are the same. What is the difference you think?

I'd really like to know the differences of the linux targets when it comes to K/N concurrency

All targets should be the same - https://kotlinlang.org/docs/native-immutability.html#object-transfer-and-freezing

I thought so too, but maybe Nick uncovered something we both don't know?

With the Linux targets there are two main ways concurrency is handled: multi-threading & multi-process Also Linux has the concept of Namespaces ( https://lwn.net/Articles/531114/ ; not to be confused with Kotlin Namespaces which are currently an idea floated by the Kotlin team - https://discuss.kotlinlang.org/t/how-do-you-namespace-things-in-kotlin/21297/5 ) that are heavily tied into multi-process, but provide some security features that would impact concurrency. It is uncharted territory with using Linux Namespaces in a Kotlin Native program since it is unknown what the side effects are, and the key pitfalls to look out for.

But the original article in question (https://kotlinlang.org/docs/multiplatform-mobile-concurrency-overview.html) has nothing iOS specific currently. It describes the Kotlin Native concurrency in general, which is applicable for all K/N targets. I find it very similar to https://kotlinlang.org/docs/native-immutability.html#object-transfer-and-freezing, and would rather merge both docs into one single doc.

@napperley Yes, the new memory model is not covered by this article. It would be eventually fixed. Not sure exactly when. Also, I don’t see anything related to multiprocessing in this article, so I don’t see any reason why something about cgroups should be said. I don’t think kotlin/Native has anything specific about multiprocessing. It just doesn’t work, as it doesn’t work with any other multithreaded application. There are a lot of articles on the internet about why pthreads and forks shouldn’t be mixed. The only difference is Kotlin/Native has implicit internal threads, which are not created by the user, which can be kinda confusing in the case when one tries to fork an application using only the main thread. Maybe we should create some single-thread compilation mode, but that’s definitely out of priority now.

@Pavel Kunyavskiy [JB] - With the program I am developing ( https://gitlab.com/data-conduit/conduit-server/-/tree/linux-namespaces ) it doesn't use the pthread API, but does use the fork and clone (required to use Linux Namespaces - https://man7.org/linux/man-pages/man2/clone.2.html ) functions, along with using some functionality from the KotlinX Coroutines library. I am not sure if the KotlinX Coroutines library is using the pthread API or not under the hood. So far no deadlocks have been encountered although that may come down to luck more than anything else. Atomic data structures don't seem to work properly (eg changes from the sub namespace aren't seen by the system namespace). As a workaround files have been used to establish communication between the sub and system namespaces, which is working reasonably well. For some reason the clone function cannot be used directly (a workaround has to be used - https://gitlab.com/data-conduit/conduit-server/-/blob/linux-namespaces/src/nativeInterop/cinterop/scheduler.def ) which is a separate issue.

Kotlin/native itself using pthreads API, by default, for example, inside GC. And I'm quite sure, coroutines does, except maybe if using only Main dispatcher.

It would be nice if there was an implementation of the KotlinX Coroutines library for Kotlin Native that didn't rely on threads. Coroutines ( https://en.wikipedia.org/wiki/Coroutine ) as a low level concurrency primitive aren't reliant on an OS to function ( https://www.embeddedrelated.com/showarticle/455.php ).