Is there any possibility that

withTimeOut

construct doesn’t throw

TimeOutCancellationException

? In my android service I am using combination of timeout + channels to send data to specified duration using channels, and the sending operation should end after specified time. I have observed that channels kept sending the data well past timeout limit. Here is my pseudocode

launch(<http://Dispatchers.IO|Dispatchers.IO>) {
                    val openChannel = openChannel(interval = interval)
                    try {
                        withTimeout(timeMillis = duration) {
                            openChannel.consumeEach {
                                doOnTick()
                            }
                        }
                    } catch (e: TimeoutCancellationException) {
                        openChannel.cancel()
                        stopService()
                    }
                }

In this code

catch

isn’t executed sometimes. This code runs properly on kotlin playground, what is wrong above?

Can someone point me in the direction about some info about

Unconfined

&

EmptyCoroutineContext

?

i’m having trouble with verification of suspending functions with mockito failing randomly. the tests most often pass, but will occasionally fail and i’m not sure why. for example:

@Test
    fun `Submits app selection if selections can be made`() {
        mainActivityViewModel.submitAppSelection(selectedApp)

        runBlocking {
            verify(mockAppsStartupFsm).submitEvent(AppSelected(selectedApp))
        }
    }

class MainActivityViewModel {
    fun submitAppSelection(app: App) {
        if (!selectionsCanBeMade()) return
        lastSelectedApp = app

        val coroutineScope = CoroutineScope(Dispatchers.Default)
        coroutineScope.launch { appsStartupFsm.submitEvent(AppSelected(app)) }
    }
}

AppsStartupFsm#submitEvent

is a suspending function. Changing the runBlocking scope to be function level doesn’t seem to help. Is there something I’m missing with verification of suspending functions?

yeah exactly @Allen Wang, the root problem is that this code doenst synchronize on the status of that

submitEvent

call

I'm getting this error while running junit test in android module

Exception in thread "main" java.lang.IllegalStateException: Module with the Main dispatcher had failed to initialize. For tests Dispatchers.setMain from kotlinx-coroutines-test module can be used

Does anyone know

Dispatchers.setMain

with what parameter should be called?

When I step through the code it fails on uiScope.launch {...} where uiScope is defined:

I found I was using actor a lot just to get concurrency safe access to some arbitrary mutable data but there’s a lot of boilerplate for even this very simple application of actor. So I made a general purpose actor for this and I was hoping someone could tell me if you see any obvious oversights in it. Like for example does passing the whole function to the actor as opposed to just some parameters cause significant performance degradation or something like that. Here is the code: https://gitlab.com/snippets/1797360

How do I integrate OkHttp to work properly with

ThreadLocal.asContextElement

? Currenlty I use retrofit with

CompletableFuture

futures and then using

async

extension function from jdr8 integration package. But the request itself is executed in OkHttp own thread pool and so my

ThreadLocal

is null there, since coroutine doesn't know about this thread.

[Android: LiveData —> Coroutines]. Probably you're aware of

NetworkBoundResource

from Google's app guide: https://developer.android.com/jetpack/docs/guide#addendum. How do you replicate similar functionality in coroutines world? Can you reuse it? Do you apply some completely different technic? Some thoughts: Case 1: network request, no caching required: Before: return

LiveData<Resutl>()

After: probably just

suspended get(): Result

? Seems enough.

Error/Success

, no need for a stream here. Case 2: network request, return cache first, update cache, return fresh data Before: return

NetworkBoundResource

as LiveData (emits two items, cached and refreshed) After? Channels? Actors? (P.S. Does anybody have an example of cache aware Repository with coroutines? )

Is there a good way to offer events to channels but ignore it if the channel is closed? Currently it seems like only try catch would work, as checking for close beforehand isn't atomic.

in a blocking world it's easy to start the coroutine and either sleep for an amount of time or wo wait on a latch or something. but these approaches wont work with js...

I am preparing Kotlin Coroutines Cheatsheet. Any suggestions? Something to change/correct?

Hello, can anyone explain channels are thread safe structure? When is a global variable

Looks like just closing the actor wasn't enough, but when I cancel the

coroutineScope { }

that contains it, it works... why should it work that way?

Let’s assume if have a function which has some part that has to be done on the main thread, and some calculations, but the whole function has to be blocking, not suspending. Is there any benefit from doing:

fun doIt() = runBlocking { value = withContext(Dispatchers.Default) { // some calculations } }

vs just doing everything on the main thread? As I understand,

runBlocking

will still block the main thread (if

doIt

is called from it), is there any practical difference between blocking the main thread by

runBlocking

and by just doing some calculations on the main thread?

Must be something trivial. Why it's not getting caught?

@Test
	fun `Channel exception error handler`() {
		val errorHandler = CoroutineExceptionHandler { _, throwable ->
			assertThat(throwable.message).isEqualTo("Failure")
		}
		runBlocking(errorHandler) {
			val channel = produce<Nothing> { close(Exception("Failure")) }
			channel.consumeEach { println() }
		}
	}

Is it possible to configure a project with kotlin coroutines/native with a gradle version different from

4.7

? https://github.com/Kotlin/kotlinx.coroutines/tree/master/native My problem is that with the new android plugin version

3.3.0

requires at least a gradle version of

4.10.1

and it got complicated to update my mpp

While migrating old code to coroutines I always encounter blocking code, like IO, synchronized blocks, wait / notify etc. Not everything can be changed to be suspending rather than blocking, so what is the worst case scenario with blocking code inside coroutines? Should I just always use the IO Dispatcher to make sure enough threads are available, or can blocking code inside coroutines have negative consequences to the point where I should explicitly not use them and stick to Thread? So for example, is

GlobalScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) { synchronized(lock) { // some operations } }

potentially worse than

thread { synchronized(lock) { // some operations } }

?

ah ok, I was thinking there might be major reworking of code needed..

Hello guys, up until now I've been using rxjava for networking but now I'm trying to change to coroutines. On rx I have a central system that if a certain property on the network response has a certain value it maps it into a custom exception How can I do something like that on coroutines? https://stackoverflow.com/questions/54204547/central-error-handling-in-coroutines-kotlin

I'm trying to emulate `PipedInputStream`/`PipedOutputStream` with coroutines, does https://github.com/Kotlin/kotlinx-io provide anything like that? currently I have a

ReceiveChannel<ByteReadPacket>

but no way to turn that into an

InputStream

for a Java API. I don't care if the

InputStream

blocks instead of suspending, but I'd like keep it in coroutines until I hit Java

I have the following block of code:

scope.launch(<http://Dispatchers.IO|Dispatchers.IO>) {
    val result = runCatching {
        fetcher(key)
    }
    receiverChannel.send(key to result)
}

The scope is currently

GlobalScope

and

fetcher

is a suspended function (that just returns an exception) Even with runcatching, I’m getting

FATAL EXCEPTION: DefaultDispatcher-worker-4
    ...
    java.lang.RuntimeException: Test

Is there something else I’m missing? Do I need to add a new scope here?

How do you structure your API with channels? A common example from docs is

fun CoroutineScope.foo(): ReceiveChannel<Int> = produce {}

What if it's in a different class? Then the usage is ... strange? 🙂

class Bar{
fun CoroutineScope.foo(): ReceiveChannel<Int> = produce {}
}

.... coroutine scope ....
bar().run {
   foo() ??
}

basically, I want my Repository to return channel and I thought

produce

is the way to go. Should I just pass

CoroutineScope

as a parameter?

any

ReceiveChannel.asLiveData()

implementations?

Can't run a suspend function in a

mapNotNull

...? It might be nice to add such extensions in kotlinx.coroutines that take suspend lambdas no (I don't know how this would work though)? Or use inline functions...

I am a bit confused about

TestCoroutineContext

. In unit testing, should I init it in classes that have

CoroutineContext

in the constructor?

Messing around with coroutines for first time. Is there a better way to implement a timer that executes a block of code every x millis? I was hoping to avoid recreating the job every time but it seems that you cannot "pause" a coroutines and start it again. Thanks in advance.