Given that K/N does not support traditional concur...

# kotlin-native

[Dico]

Given that K/N does not support traditional concurrency model, what are my options for multiplatform parallelization?
I fail to see how this design decision can be a good one when multiplatform is added to the frame. It's held me back from using K/N seriously. If someone has an answer, enlighten me please.

[olonho]

MPP is not Java-style WORA, it is way to share code amongst different platform, for example Kotlin/JS concurrency is also different, and it must be taken into account when making an MPP application

[Dico]

But js is not a desktop target, and the js platform has an inherent restriction, where it is not a design choice. Java and native targets could be used for similar purposes, and on native it was a design choice not to use a compatible or similar concurrency model. The traditional one which we're familiar with and is used at large in kotlin-jvm isn't just being discouraged, but it's outright disabled through freezing mechanics. It makes multiplatform parallelization hard and that's why I'm being critical of the choice.

Of course, I'm just an individual, and you have no obligations towards me, but as a kotlin fanatic, I would appreciate if you could try to explain why it was done like this. I get that the traditional concurrency model has problems, but I think we have the tools to use it correctly and safely, especially with coroutines. Is there any more to it? Does it make the virtual machine much easier to implement or more efficient?

[r4zzz4k]

Please correct me if I got that wrong, but do you mean that due to these decisions you don't expect people to use any kind of multithreaded concurrency in common code at all, even for sharing only between Kotlin/JVM and Kotlin/Native and ignoring JS?

[r4zzz4k]

Basically I mean, can we stop expecting multithreaded kotlinx.coroutines on K/N?

[Dico]

Thanks for that answer, this makes a bit more sense now.

[Dico]

So one limitation is presumably that mutations are not propagated to other threads very quickly, or there are no guarantees that can be built on. One has to explicitly send a mutable object to a worker, and the runtime will then take care of it. Something like that.

[kpgalligan]

“you don’t expect people to use any kind of multithreaded concurrency in common code at all” I can’t speak for everybody, but we’re using MT concurrency in common code and have been doing so for almost the past year. Currently that includes suspending functions in the main thread that delegate to background processes, and a “reactive-lite” pub/sub model that listens for changes to a local db and pushes them across thread boundaries to the main thread. In summary, we’re doing the bulk of what you’d want to do in a standard app today.

[kpgalligan]

We’d do more exotic forms of concurrency, but haven’t had much of a need yet. It’s all open source. https://github.com/touchlab/DroidconKotlin/

[kpgalligan]

I can’t speak for JB, but you should still expect multithreaded coroutines. If those plans had been abandoned, that would be big, disappointing news to me. This is new, and takes some adjustment, but I personally support progress on concurrency: https://medium.com/@kpgalligan/saner-concurrency-74b0bf8ed446

[r4zzz4k]

Thank you very much for the link to the repo, I'll definitely check this out. For some reason I was sure such a solution was not technically possible. Probably missed some change allowing to make a wrapper for Worker.execute. That's really good news!
Sorry if I sounded too negative / pessimistic, it definitely wasn't intentional.

[kpgalligan]

This is difficult to learn at first, but I think that’s because it’s new, not inherently difficult to learn. I also have some blog posts about concurrency: https://medium.com/@kpgalligan/kotlin-native-stranger-threads-ep-1-1ccccdfe0c99

[r4zzz4k]

Thanks. The idea behind mutable × shared is awesome, I've played with it a bit, struck a wall several times but even managed to implement global cache via map of atomicrefs, which appeared to be very easy despite of first impression. And thanks to your sample now I know that it's possible to have an abstraction in common code around worker maps and thread pools. So I definitely underestimated current possibilities :)
As for your blog posts, they are awesome and really helpful!

[kpgalligan]

“map of atomicrefs” See https://github.com/touchlab/Stately

[kpgalligan]

Linked list, map, lrucache, with atomic refs

[kpgalligan]

Thanks for the feedback! I think a future post will be around performance. I wasn’t thinking about that much when implementing Stately, but after some real world usage and feedback (https://github.com/square/sqldelight/issues/1226), it starts to add up and should be considered

[r4zzz4k]

Stately is 🔥, didn't see it before.
Will definitely try out as soon as I get some time 😊

[kpgalligan]

Technically, Stately is ❄️

[r4zzz4k]

That's true, my bad. 😁

[Carl Hickman]

I can’t speak for JB, but you should still expect multithreaded coroutines. If those plans had been abandoned, that would be big, disappointing news to me.

[Carl Hickman]

Same here. It’s the one technology that makes me sweat thinking about not every having