This message was deleted.

If I have code that previously used the continuation style:

doA {
  doB {
    doC()
  }
}

And I want to make them all in the same level, would it be done like the following?

// Original
fun doA(continuation: () -> Unit) {
  // some action
  continuation()
}

// New
suspend fun doA() = suspendCoroutine<Unit> {
  // some action
  it.resume(Unit)
}

Then I do something like

launch {
  doA()
  doB()
  doC()
}

Which should occur one after the other by default. My goal is just to remove the nested brackets. The reason I have continuation to begin with is that the actions I’m running deal with callbacks. Is there also a benefit to doing some potential safety checks before calling suspendCoroutine vs putting them all inside that wrapper? The delay function seems to do that.

To those who replied to my previous post, does this look good?

// Original
private fun setWebCookie(cookie: String?, callback: (() -> Unit)?) {
    with(CookieManager.getInstance()) {
        removeAllCookies { _ ->
            if (cookie == null) {
                callback?.invoke()
                return@removeAllCookies
            }
            L.d { "Setting cookie" }
            val cookies = cookie.split(";").map { Pair(it, SingleSubject.create<Boolean>()) }
            cookies.forEach { (cookie, callback) -> setCookie(FB_URL_BASE, cookie) { callback.onSuccess(it) } }
            Observable.zip<Boolean, Unit>(cookies.map { (_, callback) -> callback.toObservable() }) {}
                    .observeOn(AndroidSchedulers.mainThread())
                    .subscribe {
                        callback?.invoke()
                        L.d { "Cookies set" }
                        L._d { cookie }
                        flush()
                    }
        }
    }
}

// With suspension
private suspend fun suspendSetWebCookie(cookie: String?) {
    cookie ?: return
    val manager = CookieManager.getInstance()
    manager.removeAllCookies()
    cookie.split(":").forEach {
        manager.setSingleWebCookie(it)
    }
}

private suspend fun CookieManager.removeAllCookies(): Boolean = suspendCoroutine { cont ->
    removeAllCookies {
        cont.resume(it)
    }
}

private suspend fun CookieManager.setSingleWebCookie(cookie: String): Boolean = suspendCoroutine { cont ->
    setCookie(FB_URL_BASE, cookie) {
        cont.resume(it)
    }
}

The use of RX initially was slight overkill, given there’s no thread switching or anything really asynchronous in my logic. I’m going to ignore the error handling for now.

the concept behind with the singleton, mutating, and parsing using string split would flag for me in code review

given there’s no thread switching or anything really asynchronous in my logic

looks overkill here too unless you have something that does IO in removeAllCookies and setCookie

Ho to make this call async

videosList.forEachIndexed { index, video: BaseVideo ->
            val userData = getUserData(video)*//calling suspend function* 
            listWithData[index].userData = userData
        }

Hello, I'm using resilience4j and I'm trying to figure out a pattern: I want to a function call in a circuit breaker, but this function suspends, so the compiler won't let me do it.

decorateCheckedSupplier(circuitBreaker) {
  suspendingFunction() // compiler complains
}

How would I handle this? I've realized that I can wrap the

suspendingFunction

call in an

async

block, but then the circuitbreaker returns a

Deferred

and always succeeds, which is not what I want. What I want, I think, is to have be able to call a suspending function from an arbitrary lambda.

I have a question on coroutines. I want to launch two coroutines asynchronously and wait on whichever completes first, is this possible? The context here is that two separate server calls can be made independently and if either returns an error I want to cancel the remaining coroutine and error out.

📣 📣 📣

kotlinx.coroutines

version 1.1.0 is here! Changelog (compared to 1.1.0-alpha): * Kotlin updated to 1.3.11. * Resumes of

CancellableContinuation

in the final state now produce

IllegalStateException

. This change does not affect previous

CancellableContinuation

improvement, races between resume and cancellation do not lead to exceptional situation. *

runBlocking

is integrated with

Dispatchers.Unconfined

. Now nested

runBlocking

and unconfined calls do not hang, but share the same event loop.

is it very weird that tag set to 1.1.1?

"Kotlin/Native single-threaded workers support: coroutines can be safely used in multiple independent K/N workers." Are there examples of this?

@[removed] I would like to play with the Actor Models being made. How would I go about doing so? The

typed-actors

branch is 394 commits behind master. Should I make a fork?

First of all, Merry Christmas everyone 😄 !! Quick question, did something change in Coroutines 1.1.0 in how exceptions are propagated? Because in the kotlin module for Vert.x, there’s a test like this

@Test
  fun `test failure event method`(testContext: TestContext) {
    GlobalScope.launch(vertx.dispatcher()) {
      val async = testContext.async()
      val cause = RuntimeException()
      try {
        awaitEvent<Any> { throw cause }
        testContext.fail()
      } catch (e: Exception) {
        testContext.assertEquals(cause, e)
      }
      async.complete()
    }
  }

with

awaitEvent

implemented in this way:

suspend fun <T> awaitEvent(block: (h: Handler<T>) -> Unit): T {
  return suspendCancellableCoroutine { cont: CancellableContinuation<T> ->
    try {
      block.invoke(Handler { t ->
        cont.resume(t)
      })
    } catch (e: Exception) {
      cont.resumeWithException(e)
    }
  }
}

and now this test pass only if I do

testContext.assertEquals(cause, e.cause)

Hi. I have some problem with

Channel

. Where is my error?

Does

future

cancel the parent

Job

if the block fails exceptionally? (same behavior as

async

)

I want to make a flyweight using coroutines, where requests pass in a key and take in a value. If the value has already been requested within some amount of time, I want to reuse it, and if multiple requests are made with the same key, I only want the value to be fetched once and used for all requests. (This is very similar to this: ). Anyone should also be able to invalidate a current value, so that it is fetched again by future requests. I wrote a mock up here, but I’m wondering a few things: • Is it okay to wrap all of the channels in a single

select

? That is one of the differences here compared to the example in the video • Is the usage of

launch

within the main

fetch

method acceptable? It is there purely to send an event to a channel while allowing me to use the coroutine continuation • Is it acceptable that all the maps are global. In the example, they are all within the

launch

code. I’m not sure if this affect access from a different thread or not.

I don't see any synchronization in that code. The coroutines could conceivably run on different threads unless you give it a single threaded scope AFAIK

I wanted to get some feedback in regards to requiring proper usage of parallel decomposition (wrapping service method in coroutineScope). Currently for my library its up to the consumers to follow best practices outlined in the structure concurrency blog post.

Hi, I'm trying to implement a

race

function that would take a list of

Deferred

, await for the single fastest (biased or not, doesn't matter), cancel all the "losers", and return the value of the winner. Did someone already solve this problem, or has a clue on how to make this? Thank you!

Are Coroutines JVM specific ?

Is it possible to define delimited continuations? What is the closest analogy to Scala's `shift`/`reset` construction using Kotlin coroutines? https://www.scala-lang.org/old/node/2096

In this example, running the code will print ‘done’, ‘1 end’, then ‘2 end’, each in a different thread. However, the for loop never seems to run. If I change both

launch

to

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

, then the loops each print 3 times. What’s going on here? In production, would I be expected to specify a different context if I want the loops to produce results? Was adding the loops in separate launches not enough?

If I have

class Foo { suspend fun execute(): Bar }

and I want to limit that

execute

should not run in parallel is the simplest way (without channels) to use

newSingleThreadContext

to create one thread context in the class and use it in

withContext(executeContext)

in

execute

? Is there anything wrong with this, or a better way?

Hi! Does anyone know how to stop the threads started by the

CoroutineScheduler

? I'm trying to use coroutines from a webapp, where kotlin is loaded by the webapp classloader, so I need to cleanup all resources that I allocated. For this I have my own

ExecutorCoroutineDispatcher

that is used trough the code based on a internal

ScheduledThreadPoolExecutor

. But this seems to still startup some default thread pools...

I want an

actor

that I can cancel and restart. Is that possible?

Hi all 👋 A bunch of our test broke after bumping coroutines from

1.0.0

to

1.1.0

, this seemed to be caused by coroutines changing the exception instance under the hood. However this only occurs test packages. Is this expected behavior?

I have a pretty complex flow of some jobs I need to run. I need to ensure proper cancellation and cleanup. I’m almost there - but I have some weird logic involving the two child jobs that need to run in parallel

val actor = scope.actor<StartNewJobCommand> {
    var fatherJob: Job? = null
    for (startNewJobCommand in channel) {
        // cancel old father AND both his children if they are still running
        fatherJob?.cancelAndJoin() // wait to start new job until old job is complete
        fatherJob = launch {
            val son1 = async {
                // .. 
                // completion of this Deferred should cancel fatherJob and son2's job
            }
            val son2 = async {
                // ..
                // completion of this Deferred should cancel fatherJob and son1's job 
            }
            // fatherJob should not complete until his two sons have finished their work
            // note - only one of the two children need to finish
            son1.await()
            son2.await()
        }
    }
}

Do we have any idea when the visibility of methods like

onCompletionInternal

et-al will either be made public or disappear? I presume there's some work involving

JobSupport

that needs to happen. I'm trying to write my own class that extends

AbstractCoroutine

, but I'm having a real difficult time.

Couroutines lets you do the asynchronous work in Non Blocking thread way I used three launch{} with delay (200) in UI thread Only . So Can I say it's like Time division in UI thread . Like when first launch {} is delay(200) , then UI thread becomes Idle and second launch {} begins to execute then . Please correct me if wrong ?