I just want to stop the single one I’m in. I’ll use

return@launch

, thanks

Does

withContext

create a new (child) scope?

what do you mean “before”? You mean on the enclosing function?

Is there a library to provide extension functions for RxJava 1 types? Like

Single.await()

? The official lib only supports RxJava 2 😞

when I run GlobalScope.launch, is it backed by a threadpool? or it will run in the main thread?

maybe using

async

and

await

?

@elizarov I feel like I recently read/watched you say somewhere recently that you recommended a convention for coroutine functions, something like “if a function is

suspend

, it shouldn’t block the current thread”. Do you remember where that was (if it was in fact something you did say)?

Within a body of a

suspend

function, shouldn't the current

CoroutineScope

be accessible? Since it had to be invoked from some type of scope?

Nevermind, actually solved this in a very nice way using

select

on

send

. I just allocated an output and input channel for each worker:

suspend fun invoke(input: InputType): OutputType {
        return selectUnbiased {
            for(worker in runningWorkers) {
                worker.inputChannel.onSend(input) {
                    worker.outputChannel.receive()
                }
            }
        }
    }

Any recommendations to 'generically' (or 'generally', not referring to 'generics') have ThreadLocal variables follow the execution of a co routine that is dispatched to a different thread. I know I can do it with a custom dispatcher (I think -- haven tried yet) -- but this seems like a common design pattern.. Example in this case is log4j thread context stack and maps (CDC,MDC) -- the desired end-state is a way to bind the call stack affinity of functions - co-routines or not - with the common java convention of using ThreadLocal to do that. Of course while NOT breaking other reasons for using ThreadLocal which have no relation to call stack. Something like a XSLT with-param. The 'new' coroutine scopes are similar but they have been very 'brittle' for me as they require (in ways non-obvious to me) that the scope is lexical -- so if you call a function it loses track of the current scope. I understand some of the rationale for this -- but its actual use can be very subtle and cause difficult to debug errors. similarity is thread context variables, especially from 'third party' Java libraries - which reasonably assume that threads will not change if you are in the same call stack ( and don't hand a lambda off to a thread ... ) It seems that there is or could be some kind of library or convention to express this easily. These two language features/problems are similar in several ways -- analogous solutions in the java world include variants on conventions how class loaders are searched -- although those are fraught with inconstant or non-obvious convention differences as well -- including kotlin scripting where its more then non-obvious WTF class loader a compiled or invoked script will inherit. A general concept of how one manages non-local Affinity consistently would be very useful. Many frameworks resort to the classic 'pass a context variable to every function' to solve this. I have yet to find anything 'better' -- but even that convention fails unless you are in control of 100% of the source -- and happy to add yet another argument to every function in your app.

how to make this call parallel , where

init

and

getLastState

are

suspend

function ?

Question about unit testing. Most of my android code only relies on suspend functions idiomatically, without coroutine builders, and that causes no problems with tests. The builders (mainly, withContext or sometimes launch) are primarily used only by the end consumers of my business logic (eg, the UI presenters) .. Before structured concurrency, i was used to inject from outside the coroutine contexts in the presenter constructor , so in the main application i was passing UI/IO instances of coroutine contexts say, and in the tests i was passing an instance of something suitable for tests (typically, Unconfined). Now, after structured concurrency migration, i originally made my presenters receive coroutinescope and the IO context from outside, but I’m pretty sure there’s a better way to handle this. What's the best way to translate this kind of tests to structured concurrency? How do you usually express these tests? Thank you

Hi, I want to use the

select

clause to select between two user inputs (two button clicks). Should I implement the select clause myself in an extension function, or should I transform the button clicks to a channel, and then use the already existing select clause implementations?

Hey everybody! Wasn’t there a converter from Coroutines to RxJava1? I can’t seem to find it, I thought it will be here https://github.com/Kotlin/kotlinx.coroutines/tree/master/reactive

After a few discussions it seems that the consensus for limiting threads for certain purpose should be coroutine worker pool. In an attempt to improve my internals I'd like to migrate my bad situation that is a mix of synchronous code, callbacks and futures in a dedicated thread pool to coroutines. The application can communicate with different systems that each have their specific limitation needs. And the main application should be unaware of that. The goal is to move to fully suspend functions, but with each system being able to enfore some global limits on all the called functions.

interface Host {

   suspend fun getMovies() : List<Movies>
   suspend fun setWatched(movie:Movie) : Boolean
   
   .....
}

Imagine a lot more functions. At any given moment there should be no more than X functions running. Ideally the limit should only apply to the actual server communication and the transformation of received data, should not be limited to allow faster command enqueing. The interface does implement close() that should also cancel all running coroutines for the host. My solution with blocking calls, would be to have a dedicated thread pool as dispatcher and use withcontext for the network call, but this is not efficient and no more works if some of the calls are non blocking and can switch to IO for example. I'd really appreciate some help on how to apprehend this needs, as it's major refactoring so needs to be done correctly 🙂

Hi: if I got a function like

fun doSomeStuff() : Deferred<String> = async { /*doing something*/}

, should that be an extension function of a

coroutineContext

as it starts a coroutine?

launch {
    try {
        async { throw IOException() }.await()
    } catch (e: IOException) {
    }
}

I get an uncaught IOException. What is wrong?

I’m refactoring one interface to change function from suspend to simple. Any ideas how this can be done? Current:

Inteface T { suspend fun A: String}

Class S{
  suspend fun B(){
    val result = t.A() 
}
}

I want to change fun A to return Deferred<String> object, but not sure how to change

val result = t.A()

so the result would be the same as if A was suspend function.

Not sure how can I call my code within a non-suspend function and still return it. Here I am adding the

renderMetricTimer.tagVal(renderTemplate.mediaType.name).time {

but clearly it gives the error

suspend function needs to be call in a subroutine.

This function returns a value (

map

). Not sure how can I do this.

unless I have to do this:

return templates.map { renderTemplatePath -> 
  runBlocking {
    val result = async {
      renderMetricTimer.tagVal(package).time {
        //code
      }
    }
    result.await()
 }.toSet()
}

Obviously, I am new to coroutines, but this seems like a lot of coroutine builders, no?

I want to create an integration module for our async lib, right now it is using

CompleteableFuture

. So I thought about converting it to either

suspend fun

by using the

await

extension. Another option is to create methods that return

Deferred

. What do you think is a better approach?

I am not sure if this hasn't been already asked before, but can a deeply nested child coroutine call

cancel()

on the outermost parent's

Job

?

Trying to get this coroutines. On this code. Why do I have to specify

return@time

? Is it because my suspended coroutine is called time? Also, why can't I do the following:

return when(process.exitValue()) {
  0 -> {
         return resultsAdapter.fromJson(scanResults)
...
}

Probably has already been asked. Shouldn’t be always preferred to use withContext() instead of launch() ?

Had a friend ask this:

how do kotlin coroutines work? i.e. is it just a state machine on top of Java's threadpool?

I don't really know anything about the internals. I thought maybe someone in here would have some insight

Is there any "guide" on knowing which scope to pick when launching a coroutine? I'm not sure what exactly I should be basing that decision off of. For example, if I'm launching something that isn't directly relevant to a lifecycle, should I only use

GlobalScope

, or should I use the most localized scope I can, just so the processes stay organized?

Also, in what situation is a

CoroutineScope

not used for what is essentially an on-going

Job

with a lifecycle? That's how I've always thought about it (I believe it was mentioned in a kotlinconf talk)

Well this works, feels bad though:

private val loop = iterator {
    for (i in 0 until 10) {
        println(i)
        yield(Unit)
    }
}

fun doIteration() {
    loop.next()
}

Hello, after updating to 1.3 my build get stucked and as far i can see, it seems the thread of coroutines remain hanging in, and never stop, is something related with the scope or should i check somewhere else?