https://kotlinlang.org logo
Join Slack
Powered by
Hi there Is kotlin coroutines based on the java n...
# getting-started
e
Hi there Is kotlin coroutines based on the java nio or they have their own implementation of non-blocking io?
n
afaik coroutines aren't related to io, so...neither
✅ 1
e
Coroutines can be used for io operations, of course, but they’re not specifically for io.
c
Also, coroutines don’t magically take blocking IO and make it non-blocking. They can be used to easily move blocking IO tasks onto background thread pools, but coroutines don’t prevent the thread from being blocked. Blocking code will still block, even in coroutines
e
Thanks
"they’re not specifically for io" - what they could used for more?
I was thinking non-blocking io is the main goal of inventing coroutinies
c
They’re a mechanism for concurrency, which is to say, doing multiple things at once. And in particular, coroutines are for doing sequences of concurrent tasks. A good example is making API calls, especially if you have multiple API calls to make at once. Without coroutines, you’d have to use Callbacks, RxJava, Futures, or some mechanism like that to be able to call one API after another has finished. Alternatively, you may wish to make a bunch of API calls at the same time where one does not depend on the other, but still know when all those concurrent tasks have completed. Coroutines handles that case as well
Note that API calls are not concerned with IO/NIO, specifically, but are about long-running tasks that should be able to be scheduled and run in the background, but still have some kind of ordering among them
Coroutines are much closer to the concept of threads than blocking or non-blocking IO. But they solve a more general concurrency problem than just threading, and are much nicer to read and write than your normal methods of thread synchronization and callbacks
e
it makes me sense, thanks for the clarification. one more q...
n
would it be fair to say that cooperative multithreading is specifically well-suited to non-CPU-bound work though? e.g. network/disk
e
what the rule should I follow to know how much thread I need to handle specific workload? How much coroutines could be handled by one thread? Is it always 1coroutine stick to 1thread? Or it's possible some skew to coroutines?
n
not sure there's a rule of thumb. if the underlying thing is blocking, well...if you want to make all your network requests in parallel, and each takes 100ms, then you should have 10 threads. now, if you're using an evented networking library instead...one thread might be fine? would just have to test.
e
I’m still pretty new to coroutines, but I think the thread pool backing them is automatically managed by the coroutines library kotlin runtime.
n
e
yet another q.... let's pretend we have three suspend functions a,b,c and call them like this:
Copy code
val ar = a()
val br = b(ar)
val cr = c(br, ar)
am I right that no benefit I'll get from the coroutines in terms performance? only thing is that ode looks nicer if I'd use Future or something like this
n
I suspect you meant suspend 😜 well...they're serialized anyway. each one depends on the output of the previous one
e
Yeah, no need for concurrency there
n
now if you replace 
b(ar)
with 
b()
...parallelism is possible
e
yeah, thanks for help
c
Copy code
val ar = a()
val br = b(ar)
val cr = c(br, ar)
these are sequential, coroutines won’t speed them up. 
b
depends on the result of 
a
, and 
c
depends on both. they cannot be parallelized, even with Futures or other concurrency mechanisms
Copy code
val ar2 = async { a2() }
val br2 = async { b2() }
val cr2 = async { c2() }
val (ar3, br3, cr3) = awaitAll(ar2, br2, cr2)
these are running in parallel. You do not need one to complete in order to complete the other. This will run 3x faster than the first example
142 Views
Open in Slack
PreviousNext
Powered by