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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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.
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.