Does running a series of coroutine operations in a blocking context force all inner functionality to run synchronously? say you had something like

runBlocking {

  val (foo,bar) = doAsync({ foo() },{ bar() })
  
  val (baz,bax) = doAsync({ baz(foo) },{ bax(bar) })

  return listOf(foo,bar,baz,bax)

}

Assuming doAsync runs the inner lambdas concurrently, would runBlocking the outer scope force these to run synchronously ?

Hello All, I'm trying to build a Search functionality using BroadcastChannel api in Coroutine.

Hi there, how to add a timeout to

awaitClose

on

CallbackFlow

? (details in thread)

Hello. What is the best solution for replacing SingleLiveEvent with coroutines? Explanation: I have some events. And multiples subscribers for these events. But I need only one time to consume this event in any of the subscribers.

can someone please point to me in the kotlinx.coroutines codebase, where the logic is, that a Dispatchers.IO thread will continue on a Dispatchers.Default thread instead of spawning a new one?

stateflow

Why there are so many native targets that are mising coroutines-core artefacts? e.g. all linux targets except x64, watchosX64, mingwX86 & androidNdk

Hello 👋 Was just wondering about Flow and context (https://kotlinlang.org/docs/flow.html#flow-context). I understand that we should not be emitting new values from new coroutines but is it fine to start coroutines to fetch some data or that should still fall under

channelFlow

? e.g.

flowOf(1, 2, 3).map { 
  id -> coroutineScope {
    val first = async { retrieve(id) }
    val second = async { retrieveOther(id) }
    first.await() + second.await()
  }
}

I want to unit test an interface like this

interface Foo {
    fun flowValue(): Flow<Value>  // flow the stored value
    suspend fun setValue(value: Value)  // update the stored value
}

however the implementation is not for me to control, and sometimes

flowValue()

sometimes emit the old value several times before emitting the set value. What is the best way to test this?

Sometimes there are valid reasons that part of a Reactive System (

Flow

setup) forms a circular reference. In these cases, it's impossible to declare all parts of an overall Flow linearly; at some point we need to reference a part that hasn't been declared yet. In RxJava the idiomatic way to work around this was using

Relay

- a specialised

Subject

. Is there a

Flow

equivalent? It seems that a

MutableSharedFlow

with

replay = 0

will have the right semantics.

Is there a way to use

retry

based on a valid emitted value and not based on exception occuring? My emitted value looks like this

public sealed class BillingClientState{
        public object Initializing: BillingClientState()
        public data class Available(val client: BillingClient): BillingClientState()
        public object Unavailable: BillingClientState()
        public object Disconnected: BillingClientState()
    }

I want rety when Disconnected is triggered

Some basic question about coroutine in android. Can I assume that we should always use viewmodelScope, which associated with lifecycle whenever possible. But in some occasion, we might not have those scope, for eg. in service or receiver. In that case, is it advisable to define job and scope within, or use Globalscope?

private val job = SupervisorJob()
private val scope = CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + job)

Do you have any sample code/project that using coroutines in the android custom view? I would like to learn the best practice that handle coroutines in custom view.

Hey guys, where can I read more about this kind of behaviour?

fun A() {
B()
C()
}

fun B(){
  scope.launch{
  //call some suspending fun
   }
}

So now C will be executed before B finishes even tho B isn't suspending fun?

Hi everyone 👋 Can anybody explain me what happens with second

Deferred

in

select

when the first one returns value?

select {
   deferred1.onAwait { it }
   deferred2.onAwait { it }
}

Is it possible to have something like

SharingStarted.WhileSubscribed()

with the extra feature that if the flow has never emitted, wait for first emission before stopping? In other words, if someone subscribes but then leaves before receiving the first value, wait for it before stop. Looking at source code it seems quite easy to modify

WhileSubscribed

to do this (just add sharedFlow.first()). But we don't have the SharedFlow when creating

SharingStarted

, we only have the upstream flow which means that values in the replay cache are ignored.

(Please redirect me if this should be in #getting-started). I'm jumping in way over my head and trying to do a multiplayer game server for my first Kotlin project. I'm trying to use Ktor Websockets for client-server communication. It's my understanding that i can run the 'core game loop' as a separate coroutine and then communicate with the client websocket coroutines via channels, am i going in the right direction? My game loop does not need to be very fast at all so i'm assuming i can comfortably

delay

back to the client websocket coroutines relatively frequently to look for new input

How would you go to debug why a coroutine is being canceled? Working on Android AFAIK we can't use

kotlinx.coroutines.debug

and the debugger in Android Studio has no "Coroutines" tab.

I am manually creating “scope1” and “scope2", with “Job()” and the same coroutine name.

val scope1 = CoroutineScope(Job() + "myscope")
val job1 = scope1.launch { … }

val scope2 = CoroutineScope(Job() + "myscope")
val job2 = scope2.launch { … }

Are “scope1" and “scope2” actually the same scope, or are they different?

hi, how do you evaluate an expression that calls a suspense function? i get an error saying suspense function is not supported in evaluation

is there a way to force

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

onto a new thread? applies to

GlobalScope.future(<http://Dispatchers.IO|Dispatchers.IO>)

etc as well

Hi all, is it a bug that suspendability on a receiver lambda has to be explicitly declared? If I have

private suspend fun <T> (suspend () -> T).foo()

and

private suspend fun <T> bar(lambda: suspend () -> T)

I need to explicitly write

suspend { delay(1)  }.foo()

but it’s fine to just call

bar { delay(1) }

without suspend keyword

I’m noticing a little bit of inconsistent behavior with

invokeOnCompletion

. Given the following

launch(Dispatchers.Default) {
  val theJob = async(<http://Dispatchers.IO|Dispatchers.IO>) {}

  // do some work

  theJob.invokeOnCompletion { println() }
}

If

do some work

takes longer than

theJob

to complete, the handler block runs on

Dispatchers.Default

, whereas if

theJob

takes longer than

do some work

, the handler block runs on

<http://Dispatchers.IO|Dispatchers.IO>

.

Hey all, in RxJava, we have 

doOnNext

 operators for side-effects, like printing, etc. What is the equivalent in Kotlin Flows? AFAIK, 

onEach

 consumes the flow, and would not be appropriate there. Or am I missing something?

i’m wondering why

CancellableContinuationImpl

would have such a large retained size?

Today I needed this:

class SuspendAtomicRef<T : Any> {
    private var data: T? = null
    private val mutex = Mutex()

    suspend fun getOrSet(init: suspend () -> T): T {
        return mutex.withLock {
            data ?: init().also { data = it }
        }
    }
}

Seems pretty basic so I wonder if I am missing it in the coroutines library?

Hey everyone, just trying to confirm something here. If I call 

collect

 on a SharedFlow and then call 

delay

 within the collect’s body, will it block other subscribers from retrieving emitted messages? My expectation is that it will because my understanding of flows is that they distribute messages synchronously through subscribers.

When using

suspend

functions in Android (which get triggered from non-UI events) and you suddenly find you need a

Context

to get something done (in this instance load a preference value), what are sound approaches to adopt? I understand that storing

Context

references is a no-no, due to the potential to leak Activites.

Hello, World! It's a small thing, but I noticed that when I have a simple program with a

suspend fun main()

, the program doesn't exit at the end of the

main

. It's not big deal since I can of course manually end it with

exitProcess(0)

but I'm wondering if I'm doing something wrong, or is this normal?