https://kotlinlang.org logo
#getting-started
Title
# getting-started
e

Eugene Freeman

09/02/2020, 7:49 PM
Hi there Is kotlin coroutines based on the java nio or they have their own implementation of non-blocking io?
n

nanodeath

09/02/2020, 8:03 PM
afaik coroutines aren't related to io, so...neither
1
e

Evan

09/02/2020, 8:14 PM
Coroutines can be used for io operations, of course, but they’re not specifically for io.
c

Casey Brooks

09/02/2020, 8:17 PM
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

Eugene Freeman

09/02/2020, 9:27 PM
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

Casey Brooks

09/02/2020, 9:35 PM
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

Eugene Freeman

09/02/2020, 9:38 PM
it makes me sense, thanks for the clarification. one more q...
n

nanodeath

09/02/2020, 9:38 PM
would it be fair to say that cooperative multithreading is specifically well-suited to non-CPU-bound work though? e.g. network/disk
e

Eugene Freeman

09/02/2020, 9:43 PM
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

nanodeath

09/02/2020, 9:45 PM
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

Evan

09/02/2020, 9:47 PM
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

nanodeath

09/02/2020, 9:51 PM
e

Eugene Freeman

09/02/2020, 9:52 PM
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

nanodeath

09/02/2020, 9:54 PM
I suspect you meant suspend 😜 well...they're serialized anyway. each one depends on the output of the previous one
e

Evan

09/02/2020, 9:54 PM
Yeah, no need for concurrency there
n

nanodeath

09/02/2020, 9:54 PM
now if you replace
b(ar)
with
b()
...parallelism is possible
e

Eugene Freeman

09/02/2020, 9:54 PM
yeah, thanks for help
c

Casey Brooks

09/02/2020, 9:58 PM
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
113 Views