what’s the recommend pattern to launch a non-cancellable coroutine from within a cancellable

CoroutineScope

?

A while ago, I made a function to race coroutines (winner cancels all the losers) thanks to your help, and now that I'm planning to add it to a library since it's not in kotlinx.coroutines, I'd like to have your thoughts on its name, and ideas if any. Here's that function, currently named `raceOf`:

suspend fun <T> raceOf(vararg racers: suspend CoroutineScope.() -> T): T = coroutineScope {
    select<T> {
        @UseExperimental(ExperimentalCoroutinesApi::class)
        val racersAsyncList = racers.map { async(start = CoroutineStart.UNDISPATCHED, block = it) }
        racersAsyncList.forEach { racer ->
            racer.onAwait { resultOfWinner ->
                racersAsyncList.forEach { deferred -> deferred.cancel() }
                return@onAwait resultOfWinner
            }
        }
    }
}

Got a question, a choice between two possible answers. The end result should be a system that can halt for a certain period of time if one of the channels within that system receives a signal to do so. The scenario: Several rendezvous channels are run simultaneously, each within their own coroutine, and each corresponding to an API route. When a request for that route is called, it is sent to the appropriate channel, which processes the request and returns the response via a second channel. After this, it checks for a route-specific ratelimit header, and if it finds this header, it delays for that period of time before processing the next request. The problem: The system also needs to be able to tell every channel to halt for that period of time IF a specific “global” header is present in a response. Solution 1️⃣ Hold a nullable

BroadcastChannel<Unit>

on the top level. Every channel will call subscribe and receive on this channel at the start of processing a request. The variable will usually be null, but if a “global” header is received, it will be set to

BroadcastChannel(1)

, and the channel where this header was received will delay for the given amount of time before setting the variable to null and calling

send(Unit)

, unsuspending all the waiting channels. Solution 2️⃣ Hold the global delay target as a unix millis, or null, at the top level. Every channel will delay for the amount it time it takes to get to that unix millis if it is not null. If a channel receives the global header, it sets the global unix millis and delays for that period of time before setting it back to null.

Why does launch builder always adds Job to the new scope even when the current scope (used to launch a coroutine) uses a SupervisorJob?

Hey Guys! Is there a way to do concurrency using the same coroutine context?

async

is not working (newbie question probably)

About https://kotlinlang.slack.com/archives/C0BJ0GTE2/p1554754893034600, is it possible to use

Flow

for hot streams as well like where we use

Flux

or

Flowable

for these use cases? If yes what are the pros/cons compared to channels?

Hello, I’m experimenting with Coroutines. Is there any abstraction to do something similar as

.sample(Duration)

? https://projectreactor.io/docs/core/release/api/reactor/core/publisher/Flux.html#sample-java.time.Duration- on channel. I’d like to throttle consumer of channel to process the latest data not often than every 1s

So if I am inside a non-suspend function (that was invoked by suspend fun) how can I access coroutineContext without adding suspend to signature of function

I have some context data as coroutineContext element that I want to access inside a function without changing it's signatures

Why are almost all operators on Channels marked as obsolete, but the simple ".map" is not?

I'm looking into replacing a server-side app (kind of an API gateway) which uses RxJava with coroutines instead. Often, there are calls across 7+ different microservices, which are managed using Observables (emitted by Hystrix), which really are Single<T>, i.e. they are not reactive streams but rather emit a single value. The reactive streams are more used for orchestrating parallel requests rather than that the async nature of these calls are the real benefit. What kind of patterns for coroutines exist for replacing for example, Observable.zip, when all that you zip are streams emitting single values? Just await() ?

Hi! I wonder if there is a way to adopt the underlying resource closing interrupting approach to deal with blocking method calls like we do in Java in couroutines? I tried to use

Continuation#invokeOnCancellation

from

suspendCancellableCoroutine

but, obviously, it doesn't work this way.

I have a Coroutines extension leveraging some Java methods specified as

suspend fun <T : Any> RowsFetchSpec<T>.awaitOne(): T = one().awaitSingle()

but when it used, type inference shows

T!

, what did I miss? I have specified that

T

extends non nullable

Any

so I would expect return type

T

.

What is the simplest implementation of a coroutine that runs a function on an interval timer in Kotlin/Native? I'm only finding solutions for Kotlin/JVM so far. My end goal is to pull data 30 times per second and update my GUI with it. If further context helps, the application is built with Cinterop for Windows and my GUI is built using: https://github.com/msink/kotlin-libui

Is anyone aware of a cache utility (like guava loading cache) that works with coroutines? (ie has suspending methods, not returning deferred) I found the following solutions, but none of them do that: - https://stackoverflow.com/questions/53558215/guava-loadingcache-with-kotlin-coroutines - https://github.com/epam/CoroutinesCache

Sorry if this was already asked. There's an way that I can ignore the

delays

from coroutines in android espresso testing?

Could use a Flow<T> to replace a LiveData?

message has been deleted

hello, I got a prototype bean that is created at runtime based on some input parameters. Within the prototype bean I got multiple methods that accept value (and some others that dont) that should be computed just once (as it is pretty expensive). Since I don't want to incur the initialization penalty if I'm not going to be calling a method that needs it I was using

by lazy

. I'm migrating now to coroutines was wondering whats the proper way to update

by lazy

to call suspendable function. Any thoughts on how to make this better?

Is there any roadmap for coroutines 1.2? When should we expect stable release?

Hi guys, let me ask you a simple question. When using co-routines, will we be using all cpus available always?

Hi all, quick question for a newbie. I have a

List<Node>

. I want to run a repeated background job on each node in that list (independently), that fetches some data from a URL and mutates the node state at each iteration. At some point I want to be able to stop the entire job altogether. Do you have any pointers? I'm a bit lost with coroutines

Hi, are channels still experimental? I'm thinking of using it for a SDK and experimental API won't work for me. Documentation says channels are experimental, code tags only some subset of channel API as experimental.

Basically I have a situation where I want a 'best-effort' behavior, but with nested scopes. Do I need to declare a scope with SupervisorJob at each scope creation? I assume yes because that seems more predictable (but more verbose), but I want to make sure.

Is there a coroutines release planned to coordinate with today’s 1.3.30 release?

how to handle exceptions while using

Flow

? I was looking at the

onErrorCollect

and

onErrorReturn

but I'm not sure how to use it. I'm using the simple

try-catch

now, but I was wondering if it already has an API for that. My usecase is that I'm trying to write an offline-first approach: I first search on local storage and emit what it has, then I look online and emit the itens that aren't cached yet . I want to handle the exceptions (mostly networking ones) only if the local storage was empty in the first place.

So I've been playing with the new Flow stuff and from what I've seen, when I skimmed through the code, none of the built in functions seem to do any cancellation checks? Example:

val job = launch(Dispatchers.Default) {
    val result = myGiantList.asFlow().filter {
        cpuBoundFilter(it)
    }.toList()
}
job.cancel()

If I don't do any cancellation checks in

cpuBoundFilter

, the flow will continue to filter through everything even though it has been cancelled.

if you use

actor.offer(message)

(instead of

actor.send(message)

when the

actor(capacity = Channel.UNLIMITED)

, is there locking involved?