What's new in Coroutines 1.3.9? I can't find release notes

Are there any examples/patterns for graceful shutdown with coroutines?

Hi guys! There are scopes, like

ViewModelScope

from

AAC

, which works best for most of simple use cases, but when you want to cancel the job whose lifecycle is very specific, then there is a place for discussion. Suppose an operation should be run starting from

onStart()

call until there is a

onStop()

call. What would you suggest as good practice here to control this operation’s lifecycle? I started by creating custom scope, inside which this operation would run, then i realised, that after cancellation this scope can’t be re-used. Then I thought that creating a new scope every time

onStart()

is called is a bad idea (or not?). So I switched to a nullable variable holding a reference to a

Job

created after

launch { ... }

in

onStart()

, which I cancel in

onStop()

. Seems normal, but what if you want to cancel a lot of different jobs between `onStart()`/()`onStop()` calls? I might want a strange thing to do: having a scope, which, when you cancel it, cancel all its children job, but could be reset to allow new coroutines to run. Perhaps, I do not understand properly which logic stands behind not allowing to re-use cancelled scope. Thanks!

I'm creating a simple game loop in an Android app. I was just about to start writing this in a classic way with SurfaceView that holds and manages a Thread object. But we're in a world of coroutines now :coroutine: so why not use them also in this use-case. Do you see any potential downsides or problems with it? I'm doing something similar to this tutorial https://riptutorial.com/android/example/30741/game-using-canvas-and-surfaceview so some canvas locking, unlocking, looping and drawing

I'm trying to understand the basics of Coroutines, the basics, but I don't understand at all what "suspending" means in this coroutines topic. Let's suppose I have my suspending function

fun suspend foobar() { dostuff }

, if I call that function from a coroutine, I understand from the documentation that calling foobar will suspend the coroutine, so does that mean foobar won't be executed? Why would I want to do that? It does not make any sense in my head. I know I must be understanding something really wrong

Updated to kotlin 1.4.0 with coroutines 1.3.9 but still dont see the coroutines debugger. Am I missing something

Looking to confirm. On a

Channel

I'd use

consumeAsFlow

if and only if the Flow was guaranteed to only have a single subscriber, but I'd use

receiveAsFlow

if one or multiple subscribers were possible, right?

In article like this one : https://quickbirdstudios.com/blog/android-mvi-kotlin-coroutines-flow/ I see the view model is handling intent by using

viewModelScope

to be able to use internal suspend function, and then use

lifeCycleScope

to observe the state flow variable. That leave us with two different coroutines, doesn’t it? Now I’m trying to test my code that use a similar approach and run in the situation where one of the mocked object used from the

viewModelScope

always return null regardless of the

whenever

mocking configuration. I stoped using the

init

block of my view model to jump start the handling of intent and replace it by a suspend fun, so now my view calls that function which returns the state flow to observe instead of the variable. This solved my null-value-mocked issue. Is that a better way way? Is there anything I’m not understanding?

@elizarov do you have any thoughts or response to this comment by Ron? https://news.ycombinator.com/item?id=24197817

I'm launching a million coroutines on Dispatchers.IO that do an HTTP post and then doing a joinAll but the loop gets stuck (posts stop being sent out). If I put a delay of 2 ms between each launch then it seems to work. Would it better to create my own thread pool? Or anyone have a guess of what the problem could be? Simplified Code:

var scope = CoroutineScope(<http://Dispatchers.IO|Dispatchers.IO> + CoroutineName("myLoop"))
 job = scope.launch {
          while (this.isActive) {
                (0 until appCfg.count).map {
                    delay(delayBetweenDeviceStarts)
                    val sn = appCfg.startSn + it
                    launch{
                      //  DO SOME HTTP OPERATIONS
                    }
                }.joinAll()
          
            } 
}

Anyone got the coroutines debugger to work on As 4.1

IntelliJ reports the use of Reader.ready() as having the potential to block and thus "inappropriate" in a suspend function. But the JavaDoc says: "This method returns true if the next read() is guaranteed not to block for input, false otherwise. Note that returning false does not guarantee that the next read will block." So that leaves me thinking IntelliJ is wrong (a bug). Does JetBrains know something that is not in the documentation perhaps?

Hey folks. I'm new to Kotlin and coroutines. I have a function that will return a

Flow<Thingy>

and, in some cases, that flow/job should be cancelled if no new

Thingy

has been emitted in the past X seconds (and I'll need to close an underlying connection when the flow is cancelled). Is there any readily-available utility to achieve this? If not, does anyone have any pointers on how to do this in an idiomatic way? If I have to implement it myself, I'm thinking of implementing it as two separate functions:

getThingy(): Flow<Thingy>

and

getThingy(timeoutMillis: Int): Flow<Thingy>

.

getThingy()

would return a cancellable flow, and

getThingy(timeoutMillis)

would use the former function behind the scenes and add the timeout logic. I'm thinking of using

Timer.schedule()

in the timeout logic so I can cancel the timer and start a new one each time a new

Thingy

is emitted, but I wonder whether there's a better way to do this.

Is it possible to install a

CoroutineExceptionHandler

in a

viewModelScope

when e.g. initialising an Android

ViewModel

? I want that exceptions by every Coroutine that are then started in this scope are then handled by the handler.

I updated my MP project which uses Ktor and coroutines to 1.4.0. I am getting this failure:

Uncaught Kotlin exception: kotlin.native.concurrent.InvalidMutabilityException: mutation attempt of frozen kotlinx.coroutines.ChildHandleNode@7eec8

Anybody have any clues where to look? This same code worked in previous version…

Hi there. Kotlin/coroutines newbie here. I have a function that opens a WebSocket connection to a server. The underlying protocol is very simple: The server sends a binary message (tagged with a unique id) and the client acknowledges it's safely stored the message by replying with a text message representing the message's unique id. I'm trying to model this with coroutines, but without leaking any details about the underlying implementation (e.g., the use of WebSockets). I basically want the user of my function to do something like this:

retrieveMessages().map {
    File("the path").writeBytes(it.message)
    it.ack()
}

It's crucial that the ACK message be only sent to the server if and when the the incoming message is safely stored. That's why the ACK is explicit. I started to model this with a

Flow<*>

but I'm finding it rather cumbersome because I'd have to track all the unacknowledged messages so I won't close the connection too soon, which I think is a code smell since flows are supposed to be cold streams and therefore the underlying resource(s) should only be active while the flow is active. So for that reason I'm starting to question whether I should be using flows (or something like it) here, compared to just getting a callback to process each incoming message and sending the ACK to the server when the callback completes without errors; e.g.:

retrieveMessages { message -> File("the path").writeBytes(message) }

Thoughts?

When migrating my MP project (android+ios) to kotlin 1.4 I ran into a problem with publishing that seems to be related to coroutines

1.3.9

(the problem goes away if I use

1.3.9-native-mt

). The project has the following dependencies:

implementation "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.9"
implementation "io.ktor:ktor-client-core:1.4.0"

It's the task

compileIosMainKotlinMetadata

that fails with the following error:

e: Could not find "kotlinx-coroutines-core_concurrentMain"

Anyone else seen this?

What’s the best way to create a completable job as a child of the current scope?

Job(parent = coroutineContext[Job])

?

Hi, my use case is as follows: I have a table in postgres which contians events. I need to get batches of these events and process them in the application, processing is transactional. There is a draft implementation using scheduled thread pools, but it's quite convoluted, hard to follow and is plagued by race conditions and inconsistency. My task is to reimplement it. I wonder if there are any good methods of doing it with coroutines lib? Basically there is a 40 thread pool, each thread can process one event at a time. And there is a JPA repository that should be used in the producer (in reactive streams terminology) of those events. I need some kind of back-pressure setup, where the 40 thread pool is maximally utilized, but never overwhelmed. What are my options with coroutines? I looked at actors, but the relevant channel API seems to be obsoleted, and

consumeEach

assumes that the actor is temporary and will be closed after each message is processed, while in my case, the actor should probably persist, even if at the moment there are no new events. Another problem with actor is, that by making it unbounded I can run into OOM if there is a spike in events count, this is where I need backpressure and cannot just read events from the repository with constant rate.

I saw this example in one of @elizarov’s articles https://medium.com/@elizarov/blocking-threads-suspending-coroutines-d33e11bf4761, about making CPU intensive call non-blocking. My doubt is as long as the work cannot be broken, this piece of code may not block main thread, but how can the Dispatcher make use of all cores on the system? Won't this just run on single background thread?

suspend fun findBigPrime(): BigInteger =
    withContext(Dispatchers.Default) {
        BigInteger.probablePrime(4096, Random())
    }

is there any library or core functionality for launching a job in a specific interval? or would a "simple"

while(true) { launch { doJob() }: delay(..) }

be the preferred solution ?

Hello I'm using the new version of Room and I'd like to start using

Flow

so what I want to do is change the

List<Animals>

to a

Flow<List<Animals>>

but then, I'm losing the mappers on my

use-case

and on my

presentation

? Is there any way to keep mapping the values from the

data

layer? I mean, my dao now returns a

Flow<List<Animals>>

do I have to change also the repository return to be a

Flow<List<Animals>>

? I had a return

List<AnimalsMappedToDomain>

, but now how can I do that mapper? What would be the flow from repository to presentation using the mappers?

I’m having an initialization issue with this code :

lifecycleScope.launchWhenCreated {
            viewModel.state
                .onEach { updateState(it) }
                .onStart { inputsCollector.loadData() }
                .launchIn(this)

inputsCollector

emit values on a channel when

loadData

is called, the values are then used by a state machine. the problem here is that

inputsCollector.loadData()

is called too soon, before the function in the state machine collects the values (I guess) even though I call that function before launching the coroutine. If I had

delay(100)

before

inputsCollector.loadData()

everything works fine. Any idea how when I should called

inputsCollector.loadData()

?

private fun subscribeToViewModel() = lifecycleScope.launch(Dispatchers.Main) {
        viewModel.viewState.collect { onViewStateEvent(it) }
        viewModel.navigationEvents.collect { onNavigationEvent(it) }
    }

This code doesnt seem to work. It only collects the first flow. Do I need to have two separate

launch

statements? Is there an easier way to do this as it gets a little messy with 3 or 4 flows

General question — When out refactoring some logic out of an existing suspend function which of these is preferred/best practice? If i'm starting with this and wanted to factor out the guts of `foo`:

suspend fun doSomeWork(): Thing = supervisorScope {
  val foo = async {
    val result = async {
      fetchResultFromNetwork()
    }

    val otherResult = async {
      fetchOtherResultFromNetwork()
    }
    result.await() + otherResult.await()
  }
  
  val bar = async {
    anotherThing()
  }
  
  Thing(foo.await(), bar.await())
}

Would you go with: a) suspend fun + scope builder

suspend fun doSomeWork(): Thing = supervisorScope {
  val foo = async {
    fetchAndMergeResults()
  }
  
  val bar = async {
    anotherThing()
  }
  
  Thing(foo.await(), bar.await())
}

suspend fun fetchAndMergeResults = coroutineScope {
  val result = async {
    fetchResultFromNetwork()
  }

  val otherResult = async {
    fetchOtherResultFromNetwork()
  }
  result.await() + otherResult.await()
}

b) Extension on CoroutineScope which returns a Deferred

suspend fun doSomeWork(): Thing = supervisorScope {
  val foo = foo()
  
  val bar = async {
    anotherThing()
  }
  
  Thing(foo.await(), bar.await())
}

fun CoroutineScope.foo(): Deferred<Foo> {
  async {
    val result = async {
      fetchResultFromNetwork()
    }

    val otherResult = async {
      fetchOtherResultFromNetwork()
    }
    result.await() + otherResult.await()
  }
}

c) Something else? Any thoughts on what's preferred between the first two options? I'm aware of the conventions on suspend fun vs extension on CoroutineScope described in this video: and this blog post: https://medium.com/@elizarov/coroutine-context-and-scope-c8b255d59055 and I think both the examples above follow the convention, but I'm not sure if one is preferred in this case for one reason or another. Any opinions would be appreciated!

private fun fetchData() = viewModelScope.launch(dispatcher) {
        repository.fetchData()
                .onEach { 
                   //success
                }
                .catch { Timber.e(it) }
                .launchIn(this)
    }

Why is this still crashing my app when an exception occurs? should

catch

be catching that and not crashing?

Hey I am working on a custom coroutine dispatcher for a programming game. I was wondering if anyone has experience doing that with Javascript to create a coroutine and then manual continue it onwards to create some sort of fake multi threading

Can somebody explain me why this fails with

Test finished with active jobs

scope.launch(Io) {
    withTimeout(500) {
        while (stack.isEmpty()) {
            delay(1) // await
        }
        result.data = stack.removeFirst()
    }
}

While this completes successfully

val j = scope.launch(Io) {
    while (stack.isEmpty()) {
        delay(1) // await
    }
    result.data = stack.removeFirst()
}
scope.launch {
    delay(500)
    j.cancel()
}

A Noob question, when I print

Thread.currentThread().name

, what exactly does

@coroutine#id

indicate (I understand it's an identifier to coroutine, but what exact piece of work does it indicate)? Is it the work the current thread does from one suspension point to till it encounters another suspension point? What exactly is a

@coroutine#id

physically translates to?