DEV Community

Discussion on: Kotlin/Native Concurrency Changes…

Collapse
 
dbaroncellimob profile image
Daniele Baroncelli

I think it would be very useful to have a wrapper class that handles the typical multi-threaded coroutine operation. Which would eventually reflect the changes to the new memory management model, under the hood, when they comes.

Collapse
 
kpgalligan profile image
Kevin Galligan

Do you have an example of what you'd like to see? Most of the concurrent libraries handle freezing under the hood, so you don't really code anything different. It's being aware of the implications. So, in general, your code won't change at all. The changes coming are a loosening of restrictions.

Collapse
 
dbaroncellimob profile image
Daniele Baroncelli • Edited

Hi Kevin, I still haven't had a real chance to dig into practical code, but I had read your KotlinNative tutorial on the Kotlin website and left me more confused than I was before. I am glad to read at the end of this article that TouchLab will now be focusing on "producing content around how to accomplish certain tasks, rather than deeper explanations around the fundamentals", as it sounds to me a sensible path to make things clearer.
One of the key points to clarify in my opinion is how you can achieve multithreading when making network calls, as I also read that currently Ktor on K/N doesn't allow calls on background threads, but you are forced to suspend the call on the main thread. It would be important to understand how things will be different between the current memory management and the next one. This is why I was talking about wrapper classes, as I think it would make sense to that these changes wouldn't affect your code. By calling a wrapper class, the changes would be done just in that wrapper class, rather than in your own code.

Thread Thread
 
kpgalligan profile image
Kevin Galligan

Ktor is a special case. That is because of the way ktor specifically is architected. Ktor in Native needs work. If the new memory model landed today, Ktor would likely still have the same restriction. It has less to do with the memory model than how ktor currently integrates with URLSession.
We're still hoping they produce a version that works with the multithreaded coroutines. We (Touchlab) had to hack around that to use it.
Now, if your calls don't return huge results that need parsing, calling and suspending on the main thread isn't really a problem. That's the point of the suspend. It doesn't block. Changing threads to then initiate a network call doesn't buy much. Where this is an issue is when you have large results that get parsed on the main thread, or if you're already in a background thread and attempt a call.
Ktor was designed around coroutines, and is a great design if coroutines ran perfectly on all platforms, but they do not. We've been discussing a simple networking library alternative for a while. Using sync calls and/or making suspending calls one option rather than default. However, the value of such a library is temporary, so it's never left the discussion phase.
I don't think I explained much there. Just brain dumped. Recipe content may help, but again, keep in mind that ktor is a very special case in this mix. So much so that we may move to pushing our network calls to expect/actuals again until the MT version is resolved.

Thread Thread
 
dbaroncellimob profile image
Daniele Baroncelli • Edited

Hi Kevin, indeed in our project we have pretty small results, typically 2-3 KB Json responses (maximum 5KB).
If parsing 5KB isn't a problem on the main thread (using a suspend function), I am wondering what is actually a typical app situation where coroutines running on a background thread are necessary. I am expecting reading from a local sqlite or settings wouldn't require a background thread either.
Would you say that unless a function is cpu intensive (e.g. image processing, big file parsing, etc.), it's fine to use coroutines on the main thread?
If that is true, then I suppose MT coroutines shouldn't even be an issue for most KMP developers.