A modern programming language that makes developers happier.

kotlinlang

:point_up:Coming back to the multithreading issue... is it true that you cannot access Kotlin native objects from another thread than the owning thread?

Yes. Their is a very different concurrent shared memory model for kotlin/native than java. Basically there is no shared mutable memory.

You can pass objects between threads, or you can freeze an object so that it can't be modified and then it's accessible across multiple threads. The latter is somewhat new, and I don't think has made it into a release yet

Thanks for confirming this. Is there any rationale for this architectural decision? I'm wondering if it's a opinionated design choice or if it's related to some specific implementation detail, like GC. It seems at odds with the concept of allowing portability between platforms  and flexibility to integrate with native libraries.

Looking at the runtime, the entire memory management systems uses Thread locals. So each thread has it's own memory map and no thread is aware of each others memory state. I'm wondering if disabling this in the runtime is feasible by removing the thread locals and just using a shared global memory state.

I’d recommend reading  <https://github.com/JetBrains/kotlin-native/blob/master/CONCURRENCY.md> as it covers important aspects of vision on concurrency in Kotlin/Native. We do not support shared heap, as believe that it is not really reliable programming model. Also this memory management model allows pauseless execution + cycle collector, unavailable on other platforms. However, in interop scenarios, where there are existing APIs with different view on how concurrency to be done, we will implement some helper functionality, allowing easier debugging and implementing callbacks, executed on other threads. See this example <https://github.com/JetBrains/kotlin-native/tree/master/samples/globalState> for various solution of the global state problem.