Is there a way with

SupervisorJob

to restart a coroutine when it stops exceptionally?

supervisorScope {
  launch {
    throw Exception()
  }
}

What is the easiest way to convert ReceiveChannel<T> to Channel<T> ?

I'm using

CoroutineStart.UNDISPATCHED

to help write

CompletableFuture

alternate methods to my suspending functions for use by Java. But I see its marked as

@ExperimentalCoroutinesApi

. Any recommendations / guidelines/ alternatives to using it? Or just be ready to uptake changes? Will post my specific example this thread

i thought Kotlin 1.3 already includes coroutines package so i dont need to explicitly add dependency for coroutines?

Hi, I'm micro-benchmarking some suspended methods in Arrow and I'm wondering given I have a very simple suspend function such as:

suspend fun test(): Int = 0

What is the fastest possible way to run the function via

startCoroutine

or similar in a blocking way to obtain

0

. This question is not specific to the coroutines-core lib but what I can do with the built in lang support for coroutines. I tried several conbinations with the EmptyCoroutineContext etc and using

CountDownLatch

and was wondering if that is the the only way to run a suspended function in a blocking way without using

runBlocking

use

launch

I have a suspend function, in which I want to start an

async

block. I'm assuming this is the right way?

CoroutineScope(coroutineContext).async { ... }

Can anyone point me to a stable implementation of Event bus with Kotlin Coroutines which works along with the android lifecycles?

I'm perusing the source code for the coroutines library and I bumped into this on `CoroutineContext`:

Persistent context for the coroutine. It is an indexed set of [Element] instances.
An indexed set is a mix between a set and a map.
Every element in this set has a unique [Key]. Keys are compared _by reference_.

is there a reason for not using a

LinkedHashMap

? what are the performance characteristics of an indexed set?

Another thing which I find a bit puzzling is that I have a class like this:

class MyClass : CoroutineScope {

    override val coroutineContext = Dispatchers.Default + SupervisorJob()

    fun doSomething(): Job {
        val handler = CoroutineExceptionHandler { _, exception ->
            // ...
        }
        return launch(handler) {
            // ...
        }
    }
}

what I want to achieve is that child jobs (launched with

launch

) can fail independently. This works right now but it also works if I remove

+ SupervisorJob()

The docs say that if I add a

CoroutineExceptionHandler

to a coroutine it won't bubble exceptions up which is fine but in

SupervisorJob

I can see this:

A failure or cancellation of a child does not cause the supervisor job to fail and does not affect its other children,
so a supervisor can implement a custom policy for handling failures of its children:

A failure of a child job that was created using [launch][CoroutineScope.launch] can be handled via [CoroutineExceptionHandler] in the context.

so it implies that I can only use

CoroutineExceptionHandler

in a

SupervisorJob

yet it works without one. Did I miss something?

I tend to go against the pattern of implementing

CoroutineScope

in application components that use a coroutine lifecycle, favoring an approach using

private val scope = CoroutineScope(...)

That way the scope is not leaked by implementing the interface and it is in my opinion cleaner. It distinguishes better between using the scope and using the scope of a coroutine you created. What do you think? Why should we implement CoroutineScope the way it is suggested initially by structured concurrency?

I just want to say thank you to whomever thought of this warning.

This message was deleted.

How to unit test that a

suspend fun

suspends until a certain condition is met ? I tried the following :

runBlocking() {
    val testSource = BehaviorProcessor.create<String>()
    val subjectUnderTest = MyCache(coroutineScope = this, source = testSource)

    val loading = async(start = CoroutineStart.UNDISPATCHED) { subjectUnderTest.getCachedValue() } // Suspend function call
    assertFalse(loading.isCompleted)
    
    // Sending an element to that processor satisfies the condition
    testSource.onNext("Foo")
    assertTrue(loading.isCompleted) // This fails : isCompleted is false
}

Is there some reason why I should use the Retrofit Deferred adapter instead of just doing the synchronous .execute() and then come back to UI thread and handle the result?

The Retrofit adapter uses enqueue which means OkHttp can better multiplex over HTTP/2 and will honor per-host connection limits.

📣 📣 📣

kotlinx.coroutines

1.2.0-alpha-2 is here! It has one major feature preview: cold streams aka

Flow

to work with asynchronous cold streams of data. The primary goal of the feature preview is to explore its possible strengths and weaknesses, evaluate real-world use-cases and finally adapt and refine it. Try it, use it, break it! Full API reference for `Flow`: https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines.flow/-flow/index.html

I'm attempting to use Realm in a suspend function. Realm only allows access to objects on the same thread. Is there a way to ensure that when a suspending call is made inside that function that it returns to the same thread as the caller? I've read about ThreadLocal but i've only seen examples when launching a coroutine and not within a suspend function. Or, is the only way to control the thread switching is from the parent calling

<http://GlobalScope.xxx|GlobalScope.xxx>

? For example

suspend fun sync() {
   Realm.getDefaultInstance().use { realm ->
          val variable = realm.getSomeVar()
          val result = service.execute() //<- suspending function
          val x = variable.y //<- Error because it returns to a different thread
   }
}

Thank you

Is Coroutines

Flow

usable in multiplatform projects?

Can anyone shed some light on how you use coroutines in addition to RxJava? Specifically how you use suspending functions instead of Single/Maybe/Completable? I understand that for one-offs that works nicely, but what if you want to use that as part of your stream? Thanks

Hi guys, I need help with

Job

. When I add a

Job

instance to a

CoroutineContext

the behaviour of

async

changes in regards to exception handling. Suddenly exceptions within

async

are propagated to the default exception handler. On Android for example this causes the app to crash.

try .. catch

around

await()

don't help here. It seems that

Job

adds the default exception handler to the context. However I need

Job

so that I can cancel the context later. Here's an example (yes, it's Android but it's a generic problem, not related to Android)

class TestActivity : Activity(),
                     CoroutineScope {

    override val coroutineContext: CoroutineContext = Dispatchers.Default + Job()

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        val deferred = async {
            // App crashes here
            throw NullPointerException()
        }

        launch {
            try {
                deferred.await()
            } catch (e: Exception) {
                Log.e("TestActivity", "ERROR", e)
            }
        }
    }

    override fun onDestroy() {
        coroutineContext.cancel()
        super.onDestroy()
    }
}

How can I have the default behaviour of

async

where exceptions are only thrown on

await()

but also have the ability of a cancellable job in a context?

Is

withContext(<http://Dispatchers.IO|Dispatchers.IO>) { ... }

equivalent to

coroutineScope { ... }

efficiency-wise if invoked from

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

?

probably silly question, if i remove the

job.cancel()

from this snippet in the coroutine docs, why does playground time out entirely?

fun main() = runBlocking {
//sampleStart
    val job = launch {
        repeat(1000) { i ->
            println("I'm sleeping $i ...")
            delay(500L)
        }
    }
    delay(1300L) // delay a bit
    println("main: I'm tired of waiting!")
    job.cancel() // cancels the job
    job.join() // waits for job's completion 
    println("main: Now I can quit.")
//sampleEnd    
}

This prints:

[1a, 1b, 1c, 1d, 2d, 2e]

. Why doesn't it start with

1b

?

I want to painlessly convert some java threads code to kotlin coroutines. There is some code which creates as much threads as much as

Runtime.getRuntime().availableProcessors()

allows. Is there any common rule how much I should handle this situation in kotlin coroutines? Totally coroutines n00b here

Now that

Flow

is there, are channels still the right tool for wrapping callback APIs with `registerListener`/`unregisterListener` ? Looks like

flowViaChannel

has been written for that purpose, but I don't see a way to "close" a

Flow

like with channels and Flowables

Hey there! I'm looking for feedback. I'm trying to implement

NetworkBoundResource

with Coroutines (instead of

Executor

like the Google sample https://github.com/googlesamples/android-architecture-components/blob/master/GithubBrowserSample/app/src/main/java/com/android/example/github/repository/NetworkBoundResource.kt). I also want that

NetworkBoundResource

return a

LiveData

through the method

asLiveData()

. 1️⃣ My first try was to pass a

CoroutineScope

to the constructor of

NetworkBoundResource

, to properly manage cancellation. Pros: in this way, tasks are canceled when a ViewModel is cleared for example. Cons: My

UserRepository

methods ask for parameter a

CoroutineScope

for each call 🔗 https://gist.github.com/PhilippeBoisney/47b9eaee02df537cf7b0703707243a78 2️⃣ My second try was to use a

GlobalScope

to launch the Coroutines inside the

NetworkBoundResource

. Pros: No more

CoroutineScope

passed through `UserRepository`methods parameters. Cons:

GlobalScope

should be avoided (even if in Google sample, they use

Executor

the same way of a

GlobalScope

) 🔗 https://gist.github.com/PhilippeBoisney/4a5fc718a2b8d9735bdf2a5bfb37aebe Which one of those approaches do you prefer? If none, how will you do? :thread-please: