So what are the current thoughts around threading?...
# kotlin-natives
spierce7
04/27/2017, 3:42 PMSo 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 PMAs 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 PMOh really? passing data between threads will require serialization and deserialization? That's one of the biggest pain points around using Dart isolates.
spierce7
04/27/2017, 6:20 PMIt 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 PMthis 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.
K 1
🎉 2
😻 3
s
spierce7
04/27/2017, 6:24 PMoh, I see. 🙂
m
mikehearn
04/28/2017, 12:14 PMout of interest, why does Kotlin Native not support ordinary threading?
mikehearn
04/28/2017, 12:14 PMthat 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 PMIt'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.
olonho
04/28/2017, 12:22 PMAnd if one absolutely needs that - Kotlin/JVM could always be used
m
mikehearn
04/28/2017, 3:15 PMI'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.
mikehearn
04/28/2017, 3:16 PMMore 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.
mikehearn
04/28/2017, 3:16 PMA 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 PMNobody says "no shared memory", as you may notice, the only thing being said - "no shared object heap"
olonho
04/28/2017, 3:32 PMThe 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.
2 Views