Stan Potemkin
01/11/2021, 4:29 AMsharedFlow.collect { println("first") }
sharedFlow.collect { println("second") }
But actually 10 taps results in 10 prints of "first" message and never prints the "second" one.
Does the shared flow accept only one collector, or could it's behavior widely depend on configuration and usage?gildor
01/11/2021, 4:53 AMcollect
is a suspend function, which returns only when upstream flow is completed, which is never the case if you use StateFlow (it never completes)launchIn(scopeForThisBackroundJob)
operator, which essentially the same as:
someScope.launch { flow.collect { block() } }
Stan Potemkin
01/11/2021, 5:23 AMMainScope().launch {
sharedFlow.collect { println("value #1") }
sharedFlow.collect { println("value #2") }
}
But still only first collector gets called..KamilH
01/11/2021, 6:02 AMMainScope().launch {
sharedFlow.collect { println("value #1") }
}
MainScope().launch {
sharedFlow.collect { println("value #2") }
}
it would launch two coroutines without blocking each otherStan Potemkin
01/11/2021, 6:17 AMcollect()
blocks the logical coroutine (not a physical thread), and we can just create several logical coroutines within single physical thread to get each collect()
working within its own coroutine?
I mean:
"Physical" by operating system, not by CPU; and "logical" as just callbacks-driven systemKamilH
01/11/2021, 6:24 AMlaunchIn
operator does under the hood. Creates a new coroutine and it blocks only “itself”Stan Potemkin
01/11/2021, 6:27 AMgildor
01/11/2021, 6:46 AMtwo collects are still in the same scopeTo be precise, it’s not an issue of the same scope, it’s perfecly fine to have many coroutines on the same scope, problem that second collector not even start collecting, because first suspend and never return
Stan Potemkin
01/11/2021, 6:51 AMtwo collects are still in the same coroutine
gildor
01/11/2021, 6:57 AMStan Potemkin
01/11/2021, 7:01 AMcollect()
inside any coroutine like a detached loop with its own separate mini lifegildor
01/11/2021, 7:02 AMinside any coroutine like a detached loop with its own separate mini lifeIt’s not detached, this is the point, it’s the same as any other loop
this scope means os thread or another scope that I should learnIn general you shouldn’t worry about it, it really depends on many factors and abstracted from you by coroutines dispatcher and flow implementation
Stan Potemkin
01/11/2021, 7:05 AMgildor
01/11/2021, 7:05 AMStan Potemkin
01/11/2021, 7:08 AMcollect()
infinite (in theory) callbacks?gildor
01/11/2021, 7:08 AMStan Potemkin
01/11/2021, 7:09 AMgildor
01/11/2021, 7:10 AMStan Potemkin
01/11/2021, 7:13 AMit’s not really busy, it’s just waits and do not proceed to the next callAnd I want to modify my answer so I don't understand it like thread blocking (busy), I do understand it like callbacks waiting
declarative looking forward
gildor
01/11/2021, 7:15 AMStan Potemkin
01/11/2021, 7:27 AMlaunch()
coroutine within the current scope without having specify in hard manner MainScope
, DefaultScope
? Just "do this here in place"?gildor
01/11/2021, 7:34 AMhow can II don’t understand your question. You already can use launch directly if you are inside of another coroutine scope block, launch is an extension function for CoroutineScopecoroutine within the current scope without having specify in hard mannerlaunch()
MainScope().launch
and this is most probably wrong if you really use this codeStan Potemkin
01/11/2021, 7:37 AMgildor
01/11/2021, 7:39 AM