I'm running into an issue when using select, and I might just be missing something very simple. Maybe someone here can spot what I'm doing wrong? I have the following code:

suspend fun select(contentMap: Map<Content, VideoContentItemHolder>) = coroutineScope {
    select<Content> {
        contentMap.forEach { content, itemHolder ->
            launch { itemHolder.onClick() }.onJoin {
                content
            }
        }
    }
}

VideoContentItemHolder.onClick() is a suspending function. Basically I am waiting for any of the itemHolder.onClick() to complete, and then returning the associated Content-object. I have attached the debugger to see that onClick() successfully completes for one of the itemHolders and I enter the onJoin-block, but the select clause never gets a result. So anyone waiting for the result is suspended indefinitely.

I guess it would have been nice to have a

getCompletedOrNull()

that returns a null instead of throwing... so currently the only way is to

runCatching { deferred.getCompleted() }.getOrElse { defaultValue }

?

Is there any (planned) concept of priorities for coroutines? I imagine an example where I want some specific kind of work – i.e. user interaction handling – to be always executed first, while some cpu intensive work without real time requirements should be handled as soon as all higher priority continuations have been worked on.

I want to replace the

GlobalScope

in `GlobalScope.async { }`but without using

coroutineScope { }

- I mean I want to write

x.async{ }

- how do I do that? what should

x

be? to make it the equivalant of doing

coroutineScope { }

? is this possible? the reason I ask is because it requires a lot of reworking to use

coroutineScope { }

for this section of code

I understand that `suspend fun`s can be suspended... what happens when it (the suspend fun) calls a non-suspend

fun

? can the code in that

fun

also be suspended?

How can I cancel a coroutine I started with

startCoroutineCancellable

?

How can I catch errors thrown from/in a

launch

coroutine? Is it only possible by using

coroutineScope

and add a try catch around it?

does runBlocking create a new coroutine scope so that your jobs inside of it won’t leak on exceptions

Hey, all. 👋 Is there a platform agnostic

CoroutineDispatcher

(i.e. not

Dispatchers.Main

) that enforces a calling thread? I want to launch some tasks that return to the calling thread.

I have a

ReceiveChannel

that the caller can use to receive data sent from repeated callback. If something goes wrong, the

Channel

implementing the returned

ReceiveChannel

is closed with a

Throwable

. How can I catch this throwable? I can’t find a method on a

ReceiveChannel

that takes a callback function to handle a side-effect of closing a channel (with or without an error).

Are there any previews available for the designs going towards cold channels?

If we are talking about cold channels, are we talking only about cold start, or also about cold propagation? Because cold start is very simple thing to achieve without any additional complexity

Is there anything that is equivalent to an RxJava

Subject

with kotlinx.corotuines? There are too many edge cases with

Channel

where I risk losing events, and having to deal with them all the time is exhausting.

Is there any way to match a

BehaviorSubject

with a

BroadcastChannel

?

ConflatedBroadcastChannel

allows for the loss of events after subscription, while

BehaviorSubject

guarantees all events to be delivered. I've tried swapping to an

ArrayBroadcastChannel

to help ensure all events are delivered, but I have no way to ensure that the current value is delivered to a new subscriber upon a new subscription being opened. Any suggestions?

@spierce7 https://gist.github.com/Dico200/2879fcbd205a31d1adcf3bab1aea6882 I wrote this for you. Hope it works.

here

firstAction()

will be called even if i cancel job while coroutine is suspended by delay, what i'm doing wrong here ?

Hey folks, I have a question https://stackoverflow.com/q/54552056/1032286 would really appreciate if someone can help me with this

If I

launch

a coroutine where I call one long blocking method (some library in native code) on

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

, is it possible that this coroutine executes on a thread on which some other coroutine is running and will block execution of that other coroutine?

Is it possible to listen to a

ReceiveChannel

to get notified when it is closed, either through an error or without one (just normally closed)?

Is there a tidy way to wait for any of`n` coroutines to finish (don’t care which one finishes first, just give me the first one)

Hello there, I am following the Kotlin coroutines documentation and I am at the chapter of "Confined vs unconfined dispatcher": https://kotlinlang.org/docs/reference/coroutines/coroutine-context-and-dispatchers.html#unconfined-vs-confined-dispatcher I copy pasted the first sample code into Try kotlin website and I don't get the same result as described in the documentation:

launch(Dispatchers.Unconfined) { // not confined -- will work with main thread
        println("Unconfined      : I'm working in thread ${Thread.currentThread().name}")
        delay(500)
        println("Unconfined      : After delay in thread ${Thread.currentThread().name}")
    }
    launch { // context of the parent, main runBlocking coroutine
        println("main runBlocking: I'm working in thread ${Thread.currentThread().name}")
        delay(1000)
        println("main runBlocking: After delay in thread ${Thread.currentThread().name}")
    }

I get:

Unconfined      : I'm working in thread main @coroutine#2
main runBlocking: I'm working in thread main @coroutine#3
Unconfined      : After delay in thread kotlinx.coroutines.DefaultExecutor @coroutine#2
main runBlocking: After delay in thread main @coroutine#3

Instead of:

Unconfined      : I'm working in thread main
main runBlocking: I'm working in thread main
Unconfined      : After delay in thread kotlinx.coroutines.DefaultExecutor
main runBlocking: After delay in thread main

Any idea why ?

I have a long running job that I would like to publish progress for. Currently the API looks like this:

suspend fun performHeavyWork()

Would it be advisable to use an actor for this case? The callee should be able to receive a progress value between 0-1 (or 0-100).

i am dealing with a super slowed paged api, limited to a pagesize of 1000 currently i just reqest it concurrently and stop once the result size drops under the requested page size what would be a clean solution to request 10 pages at a time and mark which one results in less results than the requested pagesize ? i was thinking of having a fixedThreadpool process from a channel and the first one that finds the end will somehow trigger that no more jobs are being created.. but not sure how to do this and ofc its not actually guaranted that there is no shifting of data between the requests.. there might be entries added or removed 🤮

Hi all. The following function returns a channel that I later use with “consumeEach”. However, the receiver keeps getting COROUTINE_SUSPENDED. What am I not understanding/doing wrong?

actual fun observe(): ReceiveChannel<DocumentSnapshot> {
        val channel = Channel<DocumentSnapshot>(Channel.CONFLATED)
        val removeListener = documentReference.onSnapshot({
            channel.offer(DocumentSnapshot(it))
        }, {
            channel.close(it)
        })
        channel.invokeOnClose { removeListener() }
        return channel
}

How would I make a coroutine suspend until an item is not in a set

actor, fixed thread pool, a channel with 2 listening coroutines

What’s the idiomatic way to share a job between multiple callers? I’ve done this now:

val pendingJobs = Collections.synchronizedMap(mutableMapOf<String, Deferred<Stuff>>())

suspend fun getStuff(key: String): Stuff = pendingJobs.computeIfAbsent(key, ::computeStuff)
suspend fun computeStuff(key): Stuff = /* Long running operation */

but that doesn’t feel like it’s the Kotlin way.

anybody having trouble setting breakpoints in suspend functions?

So, as a library author, if you choose to create some type

MyWorkingThing: kotlinx.coroutines.Job

, what kinds of things should you do with cancellation? In my case,

MyWorkingThing

acquires a resource that I would like to synchronize on the disposal of before letting the job hit the

Compelted

state. The

Cancelling

state seems to reflect this well: if you hit

cancel()

on a job, it goes

cancelling

while it attempts to clean up its resources. The problem is cleaning up those resources is itself a long-running operation, and I cant suspend something while its being cancelled because, well, its being cancelled. Should I just block? Should I just document

MyWorkingThing

with some docs to the effect of:

hey, if you cancel a

MyWorkingThing

its going to launch some teardown jobs in global scope.