launch(context + job1 + job2){}

is it possible to use 2 different parents to control child lifecycle? well, i know it's not. but what best way to achieve such functionality?

private val callbackContext = ...

fun request(...) {
  pendingJob?.cancel()
  
  pendingJob = launch(callbackContext) {
    delay(DEBOUNCE_PERIOD)
    ...
    suspendingFun()
    ...
  }
}

suspend fun suspendingFun(...) {
  someApi().await()
  ...
}

This used to work fine in version 0.12. Currently on version 0.14, the launch block doesn't seem to execute more than once anymore. Not sure what the problem is

scala on the other hand works with the parent interface: CompletionStage https://github.com/scala/scala-java8-compat/blob/master/src/main/scala/scala/compat/java8/FutureConverters.scala which looks on a first glimpse as a perferred approach?

what is similar to C#‘s

Task.WhenAll()

in kotlin?

Trying not to shoehorn coroutines where they don't fit well (especially since I'm unfamiliar with them) Do coroutines sound like a good fit for that?

Tweet to Baruch…

Wouldn't it be preferable to have the Delay interface not depend on java.util.concurrent.TimeUnit?

suspend fun delay(time: Long, unit: TimeUnit = TimeUnit.MILLISECONDS) {
        require(time >= 0) { "Delay time $time cannot be negative" }
        if (time <= 0) return // don't delay

Wouldn't it be more comfortable to not have require(time >= 0) Especially, as the implementation for time < 0 follwos right on the next line

I was trying to keep coroutine related code away from the presenter, but let me try your thing

Don't you have to await the future? I would guess, something like this will throw:

fun main(args: Array<String>) {
    val f = future {
        throw RuntimeException("Hello!")
    }
    f.await()
}

What would be your suspending function then? I would say putting runBlocking around non suspending code is a noop. What are you trying to achieve?

@Ian Here comes the code. You provide inBackground(), main demonstrates how your users should apply it:

fun inBackground(doWork: suspend () -> Unit) {
    launch(CommonPool) {
        try {
            doWork()
        } catch (t: Throwable) {
            // Do Logging, rethrow, ...
        }
    }
}

fun main(args: Array<String>) {
    inBackground {
        println("before delay")
        delay(100)
        println("after delay")
    }
    Thread.sleep(100000)
}

Ideally, inBackground() should be inline. But that is not yet supported.

Does anyone know a way to invoke a method that contains a coroutine from a Unit Test? for example calling this initialize() here from a test: https://github.com/voghDev/HelloKotlin/blob/coroutines/app/src/main/java/es/voghdev/hellokotlin/UserDetailPresenter.kt (found Tony Owen's workaround but I'd prefer another solution: https://medium.com/@tonyowen/android-kotlin-coroutines-unit-test-16e984ba35b4)

i’ve played around and i’ve that now:

var results = listOf<SearchResult>()
        runBlocking<Unit> {
            results = providers.map {
                async(CommonPool) {
                    it.search()
                }
            }.map { it.await() }
        }
        return results

@nekoinemo Is there a way to have it block until it hits the first suspension, as

thread {}

appears to do?

@nekoinemo Sorry if this is what you meant, but what I’m hoping for is something that will block only until the first suspend is hit, then it will return to the calling code - but the remainder of the block will be executed once the suspend resumes

how does one use the

context

field? seems like a map but i don't get what the key is

also i'm trying to use

newFixedThreadPoolContext

to create a fixed amount of threads to run my function on..but i think i need to know the thread id it's running on (0 or 1..n)

I guess I get a performance win if, rather than use the blocking

readMessage

method, I write a suspending function on top of the event-callback for https://msdn.microsoft.com/en-us/library/windows/desktop/aa365788(v=vs.85).aspx

Ok thanks

Hello everyone. Do you know whether there Is any built-in mechanism to emulate rx's `BehaviorSubject`/`ReplaySubject` on `Channel`s ?

I want a simple future library that would carry the response from a callback and outside the block I have future.get which awaits

@elizarov We already use runAsync1 for many months in production and have seen that the CPU load is more a theoretical than practial problem. I really like the way with Executors (never thought of it), thanks for this input! But of course we would like to switch to coroutines. So probably we have a blocking problem. We will investigate further why our backend doesn't work when we change runAsync1 with runAsync2.

Is there a way to run suspending code in blocking mode reliably?

runBlocking

seems to give up immediately it encounters an interrupt, leaving the suspending function in a possibly corrupt mode. Or maybe I'm only overthinking this? 🤔

it looks more complicated

In fact, I think C2 can do that, too, when the stars are right.

They are serializable right now. You can convert them to byte array with your favorite serialization framework. You just have to provide serializable context and make sure that all the locals are serializable. Then you can parcel the resulting byte array. I'm curios as to what is your use-case, though?

Is coroutines in 1.1?