https://kotlinlang.org
Join Slack
In this code will the fist collect finish before the second collect is started or is possible that t...
# coroutines
l
In this code will the fist collect finish before the second collect is started or is possible that the execution will interleave?
Copy code
val singleThread =   newSingleThreadContext("SingleThread")
val flow = flow { 
 emit("a")
 blocking call
 delay(1000)
 emit("b")
}.flowOn(singleThread)

launch(<http://Dispachers.IO|Dispachers.IO>) {
    flow.collect {
        println(it)
    }
}
launch(<http://Dispachers.IO|Dispachers.IO>)  { 
    flow.collect {
            println(it)
    }
}
o
interleaving is impossible here because the collects are linear, one must finish before the other can even be called
if you were to launch them separately, then I would say that they could interleave
l
this is what makes coroutines so difficult to work with I can't be sure if they will interleave or not if I lauch them separately, is this documented anywhere or how am I to verify this?
o
why is it difficult to work with if launched separately? it's like asking "if I start two programs, will one finish before the other" -- obviously you can't know the answer, they're executed concurrently, not in any ordered way
if you want them to be ordered, you must place some sort of ordering guarantee, otherwise, you cannot assume they are ordered, as you asked for concurrency by using two separate coroutines
☝️ 1
l
it adds another dimension to shared mutable state. here I have 1 thread so I know I can share mutable state between coroutines. I just can't tell when they overlap because the scheduling of the coroutines is not documented or obvious in anyway
o
I don't think they should document the scheduling, I don't even know if they can deterministic-ally say when one will switch to the other. That's partially up to the OS you're running on to pick which threads to run
l
my execution is on 1 thread
nothing to do with os
o
no, you're launching on the IO dispatchers
`collect`'s block will be running on the IO threads
l
oh true so it seems that it must switch between the collects if they suspend
o
basically, yes. if one isn't doing work, the other can run -- this even applies to that 
delay
you have in the single-thread section, that can allow the other flow to start processing, because the thread is available for executing work
l
Copy code
.flowOn(singleThread)
code that runs can only be in 1 thread though
so I should be able to share state
o
flowOn
only affects code prior to that call -- you can use e.g. HashMap safely, but you may not assume that the block runs to completion before another one starts
if you want that, you should probably use 
Mutex
to ensure that it can't execute simultaneously (it's basically a suspending lock)
👍 1
r
You are correct that there's no guarantee of execution order of the blocks within those launch calls. They can each be executed on a different thread (within Dispatchers.IO thread pool).
l
@Rechee Jozil the order is not the problem the problem is the interleaving
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by