Is there a better way to write this?

runBlocking {
        coroutineScope {
            withTimeoutOrNull(10000L){ // wait time mili seconds
                val a: Deferred<Unit> = async { s.deleteItem(xyz) }
                 val b: Deferred<Unit> = async { s.deleteItem(abc) }

                      launch {
                           a.await()
                            b.await()
                        }   
                 }
          }
  }

My async calls returns Deferred<Unit> but I thought it might be better to explicitly call await() on each of them as this would force the tasks to go back in the main thread. I prefer to do it this way because I'm using AWS lambda and I read somewhere that the lambda can freeze/terminated if the tasks stays in the background thread, see https://stackoverflow.com/a/39668749

@Ovsyannikov Alexey @Lulu https://github.com/Kotlin/kotlinx.coroutines/issues/1080

This message was deleted.

Hi! I need a bit of help understanding the IO talk on Coroutines. At this point in the talk (see the link) they have a code sample which shouldn't compile. And even if it compiled, I don't see how it would work across a

lifecycleScope

cancellation. What code did they have in mind? How does it work? Many thanks.

I'm seeing a behavior change between kotlinx-coroutines-core:1.1.0 and kotlinx-coroutines-core:1.2.0 when testing a cancel of launched coroutine within runBlocking (runBlocking is associated with Main dispatcher and launched coroutine with Default dispatcher) 1.1.0 -> runBlocking waits for the CancellationException handling 1.2.0 -> runBlocking finishes before handling of CancellationException Is this on purpose?

@RunWith(JUnit4::class)
class CoroutineTest {

    @Test
    fun `test coroutine cancel`() {

        var backgroundWorkCanceled = false

        runBlocking {
            val scope = CoroutineScope( Dispatchers.Default + Job() )
            scope.launch {
                try {
                    backgroundWorkCanceled = false
                    delay(3000)
                } catch( e : CancellationException ) {
                    backgroundWorkCanceled = true
                }
            }
            delay( 2000 )
            scope.cancel()
        }

        assert( backgroundWorkCanceled )
    }
}

If I have a channel, how can I “channel.take(5)“, ie. get a list containing the 5 items I would get if I channel.receive() 5 times?

i guess i could do something like:

flow {
    while (true) { emit(x); delay(y); 
}

if I have a coroutine like this:

val  deleteJob = runBlocking {
                    withTimeoutOrNull(10000L) {
                        launch(<http://Dispatchers.IO|Dispatchers.IO>) { s.deleteItem(xyz) }
                        launch(<http://Dispatchers.IO|Dispatchers.IO>) { s.deleteItem(abc) }
                    }
                }

which one of these is the best way to handle a couroutine that timedout?

if(deleteJob!!.isCancelled){
                    //do something
                }

// or

if(deleteJob == null){
                    //do something
                }

In my case

withContext(IO)

is leaking scope through global queue after parent scope cancelation. Explicit

withContext(coroutineContext + IO)

works as expected. (Example in thread)

I’m trying to set up a minimal example that gives race conditions. Any suggestions? The best I’ve got is this https://pl.kotl.in/4yU_BS_qv but it has a quirk that I don’t understand. (Question embedded in the code snippet).

How do you use coroutines in multiplatform tests? Do you need to

expect

runBlocking functions?

Can this be simplified?

Hi one of our servers crashed last night with this error:

Failed to start thread - pthread_create failed (EAGAIN) for attributes: stacksize: 512k, guardsize: 0k, detached. 
Exception in thread "HTTP-listener-11490-1" java.lang.OutOfMemoryError: unable to create native thread: possibly out of memory or process/resource limits reached 
at java.base/java.lang.Thread.start0(Native Method)

at java.base/java.lang.Thread.start(Thread.java:803) 
at java.base/java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:937) 
at java.base/java.util.concurrent.ThreadPoolExecutor.processWorkerExit(ThreadPoolExecutor.java:1005) 
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) 
at java.base/java.lang.Thread.run(Thread.java:834)

It definitely wasn't running out of memory. We do spawn a lot of coroutines, however my understanding is that shouldn't be an issue. The one place we use coroutines is:

val pushNotificationService = this.pushNotificationService
GlobalScope.launch {
    pushNotificationService.sendPushKit(id)
}

Any ideas what could be going wrong? Thanks

is it ok to use

continuation.isCompleted

i have used this and its working fine, is it ok ?

suspend fun <T> Task<T>.await(): T {
    return suspendCancellableCoroutine { continuation ->
        addOnSuccessListener {
            if (continuation.isCompleted.not())
                continuation.resume(it)
        }.addOnFailureListener {
            if (continuation.isCompleted.not())
                continuation.resumeWithException(it)
        }
    }
}

because i want to do nothing when Firebase callback is called twice

hey guys, short question: Is there a way to define a block which is a suspend function?

suspend fun magic(token: String) {}

fun tokenMagic(refreshToken: String, work: (String)->Unit) =
        runBlocking {
            fetchToken(refreshToken)
        }?.let(work::invoke)

fun example() {
    tokenMagic("42") { token ->
        magic(token) // magic should be only called from a coroutine
    }
}

I would like to execute "work" within a runBlocking block, so that I doesn't need to add a runBlocking statment for each usage of

tokenMagic

is it possible with

joinAll

that it throws

CancellationException

when this occurred in any of the

launch {}

?

Are channels considered safe to use in production? I know that experimental doesn’t mean unstable, necessarily

What is the reason behind that

CancellationException

does not cancel the parent

Job

?

I have a class which is not allowed to access certain objects from multiple threads. (Similar to a database). The function

newSingleThreadContext

should do what I want but that creates its own thread pool, which will cause unnecessary thread switching. The doc links to issue #261. Is there an update on that issue?

What’s the difference between

coroutineScope

and

withContext(Dispatchers.Default)

? They both launch a suspend block with context

Dispatchers.Default

. Is

withContext

the same as

coroutineScope { ... }.join()

? Is there a version of

withContext

that defaults to use

Dipsatchers.Default

similar to how

coroutineScope

uses

Dispatchers.Default

?

What’s the easiest way of achieving parallelization for something like

myList.map { myCpuIntensiveTask(it) }

?

What does it mean to declare main as

suspend

, ie.

suspend fun main() { ... }

? Is it equivalent to having

fun main() = runBlocking { ... }

or something else?

Hi, I'm coming to coroutines from RxJs. And I'm looking for the equivalent of

switchMap

where showing search results while the user is typing. And I want to cancel all the previous requests to the server, just have the last one. In RxJs you use

switchMap

for that. What's the coroutine equivalent?

Why does this fail immediately with

java.lang.IllegalStateException: This job has not completed yet

?

kotlin
  @Test
  fun remoteConfigWorks() = runBlockingTest {
    val remoteConfig = FirebaseRemoteConfig.getInstance()
    val worked = suspendCoroutine<Boolean> { cont ->
      remoteConfig.fetch().addOnCompleteListener {
        if (it.isSuccessful) {
          cont.resume(true)
        } else {
          cont.resumeWithException(it.exception ?: AssertionError("Fetching was not succssfull"))
        }
      }
    }
    assertThat(worked).isTrue()
  }

Could an operator like the following be added to Flow? The debounce operator is already added, but I need one with a different timeout depending on the item. It shouldn’t be too difficult to modify the current operator to add this. I can explain my use case for this operator if needed.

fun <T> Flow<T>.debounce(timeoutMillis: (T) -> Long): Flow<T>

This explains better what i am trying to achieve Say in my onStart function i call a function to get some content as soon as the activity has started.. override fun onStart() { super.onStart() contentSelectionPresenter.getAvailableContent() } And in the presenter i want to do this.. override fun getAvailableContent() : List<ContentItem> { contentSelectionView.showProgress() // Needs to run on Main thread val availableContent = contentSelectionInteractor.getAvailableContent() // needs to run on worker thread contentSelectionView.hideProgress() // Needs to run on Main thread return availableContent }

override fun onStart() {
       super.onStart()

       launch { contentSelectionPresenter.getAvailableContent() }
   }

and whatever is within the launch block will be in a CommonPool thread and can be suspend fun

private fun fibonacci() = GlobalScope.launch(Dispatchers.IO) { val result = fib(25) withContext(Dispatchers.Main) { textViewCalculating.text = result.toString() } }