https://kotlinlang.org logo
Title
s

spierce7

04/27/2017, 3:42 PM
So what are the current thoughts around threading? The concurrency sample passes messages back and fourth, but once this is implemented in Kotlin, what will the limitations be that constitute a message? I.e. if I have an immutable object of my own design will I be able to return that from a thread as a result?
o

olonho

04/27/2017, 5:55 PM
As long as it could be serialized and deserialized - yes, or if it big data in C heap, and ownership is controlled by your own proto
s

spierce7

04/27/2017, 6:18 PM
Oh really? passing data between threads will require serialization and deserialization? That's one of the biggest pain points around using Dart isolates.
It makes it VERY difficult working with large data sets that require large amounts of serialization and deserialization. Not to mention it's VERY painful. There won't be any way to return an immutable object between threads?
o

olonho

04/27/2017, 6:23 PM
this area need to be further designed, and we hope that we can build an API around coroutines and workers where object passing will be both nice and lightweight. So stay tuned, I've only described options available immediately.
:kotlin: 1
🎉 2
😻 3
s

spierce7

04/27/2017, 6:24 PM
oh, I see. 🙂
m

mikehearn

04/28/2017, 12:14 PM
out of interest, why does Kotlin Native not support ordinary threading?
that seems like a surprising design choice given that Kotlin/JVM is rather un-opinionated when it comes to controversial topics, and generally lets people go their own way.
o

olonho

04/28/2017, 12:21 PM
It's not a question of threading, it's question if shared object heap. Being JVM developer for quite a few years, I find that shared object heap gives lots of complexity with very dubious benefits.
And if one absolutely needs that - Kotlin/JVM could always be used
m

mikehearn

04/28/2017, 3:15 PM
I'd say that's a rather strong view. Visual Basic (pre .NET) worked the way you describe. It was universally considered a problem rather than a solution. In practice because shared state is often mandatory for any given problem, and thus you end up wanting to do a lot of messages, and then you want to simplify the process with some sort of RPC, hence VB used DCOM to let threads communicate, and then that opens you up to re-entrancy issues, other kinds of deadlock and so on.
More to the point, what is the target market for Kotlin Native? I thought it was similar to the target market for C++. So, people will want to exploit the hardware maximally.
A change as basic as "no multi-threading", because shared memory is what defines threading (vs just processes), will essentially mean Kotlin/Native is a different language from Kotlin/JVM and much software simply won't work on both.
o

olonho

04/28/2017, 3:28 PM
Nobody says "no shared memory", as you may notice, the only thing being said - "no shared object heap"
The most popular language in the Universe (yes, JavaScript) lives just fine without shared object heap, and it doesn't prevent development of very complex and efficient applications, such as Google Maps or GMail.