With the Kotlin Native documentation there is an a...

# kotlin-native

[napperley]

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.

[Arkadii Ivanov]

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?

[napperley]

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

[Arkadii Ivanov]

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

[andylamax]

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

[Arkadii Ivanov]

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

[andylamax]

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

[napperley]

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.

[napperley]

One thing that isn't covered in the Kotlin Native documentation is handling data (input & output) with Linux Namespaces between multiple processes/threads.

[napperley]

@Pavel Kunyavskiy [JB] - As I understand it the current Kotlin Native documentation on concurrency is outdated since it doesn't cover the new Kotlin Native memory model, and big developments with some platforms that affect concurrency (eg Linux Namespaces).

[Arkadii Ivanov]

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.

[Arkadii Ivanov]

You can easily remove "Mobile" words, and replace "iOS" with "Native" and the article still will be valid.

[Arkadii Ivanov]

From my point of view, the point of the article is to describe the specifics with sharing data between threads - like shared XOR mutable, freezing concept, sharing singleton objects and top-level properties, etc. Which is valid for all platforms.

Also iOS is not the only one mobile native target. There is a family of androidNative targets as well. Not sure if it's included in the term "Kotlin Multiplatform Mobile" though.

[Pavel Kunyavskiy [JB]]

@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.

[napperley]

@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.

[Pavel Kunyavskiy [JB]]

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.

[napperley]

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 ).