Property delegation to a

(Mutable)StateFlow

may be useful 🙂

val state by someStateFlow()
…
println(state)

var foo by someMutableStateFlow()
…
state = newFoo()

Is

StateFlow<T>

mapping a planned feature? Right now I stick with Flow instead of StateFlow<T> because it stops me from doing something like this:

// Example 1
val name: StateFlow<String> = ...
val greeting: StateFlow<String> = name.map { name ->
    "Hi, $name!"
}

// Example 2
val a: StateFlow<Int> = ...
val b: StateFlow<Int> = ...

val sum: StateFlow<Int> = combine(a, b) {a, b -> a + b }

📣 📣 📣 kotlinx.coroutines 1.4.0-M1 is here! •

SharedFlow

for managing hot sources of data •

shareIn

and

stateIn

operators to transform a cold

Flow

into a hot one • Channel cancellation atomicity is reworked, and API for closeable resource transfer is introduced And more, full changelog: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/1.4.0-M1

is there an issue for tracking “sliceable dispatchers”?

Is there a way to access coroutine information during debugging without using breakpoints?

No coroutine information found

Target VM is not paused by breakpoint request. Evaluation of methods is not possible in this mode

Just realized that SharedFlow was only released today, so maybe I need to be a little more patient

val coroutineContext = parentScope.coroutineContext + CoroutineName("foo")

Is there a difference between

GlobalScope.launch(coroutineContext) {…}

and

CoroutineScope(coroutineContext).launch {…}

?

MutableStateFlow

is great for passing around a shared cache, or is it? 🤔

Hi! I currently have this pipeline:

val input: Flow<MyObject> = ...
val output = input.map { it.toOtherObject() }

I would like the calls to

toOtherObject

to be ran in parallel, and I would like an exception in one call not to stop the others. I tried:

val scope = CoroutineScope(SupervisorJob() + Dispatchers.Default)
val output = input.map {
  scope.async {
    it.toOtherObject()
  }
}.map { it.await() }

But this is still sequential, and not parallel. What am I doing wrong?

Hey everybody. I have a quick question. In this example, why does

joining

occur before

second started

? I’m running this in IntelliJ if that makes any difference.

fun main() = runBlocking {
    val job = GlobalScope.launch {
        val deferredOne = async(<http://Dispatchers.IO|Dispatchers.IO>) {
            println("first started")
            delay(1_000)
            println("first finished")
        }
        val deferredTwo = async(<http://Dispatchers.IO|Dispatchers.IO>) {
            println("second started")
            delay(2_500)
            println("second finished")
        }
        println("joining")
        deferredOne.join()
        deferredTwo.join()
        println("complete")
    }
    job.join()
}

This is the output.

first started
joining
second started
first finished
second finished
complete

Is there a way to check if coroutines are available?

if (coroutinesAvailable) GlobalScope.launch(<http://Dispatchers.IO|Dispatchers.IO>) { … } else …

Why

Flow<T>.collectWhile(predicate)

is internal in kotlinx.coroutines.flow ? It could be useful to suspend a coroutine till value matches some predicate. Is

Flow<T>.first(predicate): T

considered to be used (as it utilizes the collectWhile) or something else to be used?

Is all that parking overhead from coroutines? Are there approaches to get that down? Looks like that 50% of the application’s CPU time is spent on locking.

Hello! I’m currently having an issue where wrapping a callback + switching the context will throw even when wrapping everything inside a Result. The weird part is that I’m not throwing anything, just creating a Result.failure with the exception. Removing withContext will fix the crash, but then I’m not sure how to run on another thread (Code inside the thread)

Hi, I need something like AtomicReference in KMP project, any ideas?

Is low level synchronized block still cool in coroutines? The usual copy load+save use case... Or maybe updating StateFlow instance via reducing of the current value + change

Is having a single threaded dispatcher or semaphore more idiomatic?

What is the correct way of catching an exception in

Flow.flatMapMerge

? I have this:

val f: Flow<CustomObject> = ...
f.flatMapMerge {
  it.customFlow()
}

This works fine as long as there is no exception, however if there is one, the entire flow is cancelled. I tried to write

f.flatMapMerge {
  try {
    it.customFlow()
  } catch(e: Throwable) {
    println("Caught")
    emptyFlow()

}

} but that still cancels the flow, instead of just skipping items for which the conversion fails.

Is there a way to pass events from websocket to view model without RxJava and callback? RxJava is just to big to implement in my project just for this need. Flow is still not ready for production (is it?) And liveData does not seem like a good fit (no need for lifecycle awareness in this case)

How do I write

Observable.just

with channels?

Hi, im migrating from rx java. Is there a way to make this flow synchrounous on main thread in android?

class MainActivity : AppCompatActivity() {

    private val scope = MainScope()

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

		Log.d("Default", "a")
        scope.launch {
            Log.d("Default", "b")
            flowOf(1)
                .collect { Log.d("Default", "coll=$it t=${Thread.currentThread().name}") }
        }
        Log.d("Default", "c")
    }
}

prints:
2020-10-18 04:14:26.808 21786-21786/sk.foo.flowplayground D/Default: a
2020-10-18 04:14:26.808 21786-21786/sk.foo.flowplayground D/Default: c
2020-10-18 04:14:26.848 21786-21786/sk.foo.flowplayground D/Default: b
2020-10-18 04:14:26.851 21786-21786/sk.foo.flowplayground D/Default: coll=1 t=main

I want:
2020-10-18 04:14:26.808 21786-21786/sk.foo.flowplayground D/Default: a
2020-10-18 04:14:26.808 21786-21786/sk.foo.flowplayground D/Default: b
2020-10-18 04:14:26.848 21786-21786/sk.foo.flowplayground D/Default: coll=1 t=main
2020-10-18 04:14:26.851 21786-21786/sk.foo.flowplayground D/Default: c

is it common practice to pass around a coroutine context? I come from the C# world, and I’m trying to figure out how to actually call suspend functions

Has anyone had success evaluating an expression with the debugger recently? Getting

Class 'androidx.compose.ui.layout.LayoutCoordinates' is compiled by a new Kotlin compiler backend and cannot be loaded by the old compiler

etc

Hi, im trying to learn coroutines/Flow I want to subscribe my

viewModel.state

flow in android Activity, between onStart and onStop I do that, and notice that after having activity.onStop called, next activity.onStart doesn't start listening to the flow So I conclude scopes are not reusable But this is android reality and I need that. I need equivalent of rx

compositeDisposable.clear()

Is the only solution to have abstraction over the scope which will create new scope instances?

Hello everyone, has anyone had any issues related to coroutines/ktor/multiplatform? So when using the

1.3.9-native-mt-2

it works on iOS but not for Android • const val kotlinCoroutines = “1.3.9-native-mt-2” With

1.4.0-M1

works for android but not iOS • const val kotlinCoroutines = “1.4.0-M1"

is there any way to find the origin of a JobCancellationException on Android ? There is no stacktrace displayed in logcat 😢 the debug probes still doesn't look available

which is better the first block or the second?

scope.launch {
            while (isActive) {
                launch {
                    val record = aKafkaConsumer.poll(Duration.ofMillis(200))
                    log.debug().log("[received records] - count={}", record.count())
                    record.forEach {
                        callback(KafkaMessage(it.key(), it.value()))
                    }
                }
            }
        }
        
 
        scope.launch {
            while (isActive) {
                val record = aKafkaConsumer.poll(Duration.ofMillis(200))
                log.debug().log("[received records] - count={}", record.count())
                record.map {
                    launch {  callback(KafkaMessage(it.key(), it.value()))    }
                }.joinAll()
            }
        }

Unique CoroutineName per child coroutine Right now if you pass a CoroutineName in a context, that name is propagated down to children Coroutines. I guess this makes sense. That's behavior for any context element except for Job. I think it would be nice to give children Coroutines unique names based off their parents CoroutineName. Does that make sense? In the end... I would like a way to identify children Coroutines vs top level Coroutines. Is there a way to do this?

Hi! I'm running into an issue with

Mutex.withLock

and unexpected freezing in my iOS app when upgrading my project to kotlin 1.4.10 and coroutines 1.3.9-native-mt-2. I think I have been able to make a simple reproduction case:

runBlocking(newSingleThreadContext("thread")) {
    val mutex = Mutex().apply { ensureNeverFrozen() }
    launch {
        runCatching { mutex.withLock { delay(1000) } }.exceptionOrNull()?.printStackTrace()
    }
    launch {
        runCatching { mutex.withLock { delay(1000) } }.exceptionOrNull()?.printStackTrace()
    }
}

This launches two coroutines in the same worker. Both tries to take the lock and then delays for 1 sec while holding it. As everything happens within the same worker thread I would not expect any mutability issues. But... This is what happens:

kotlin.native.concurrent.InvalidMutabilityException: mutation attempt of frozen kotlinx.coroutines.sync.MutexImpl.LockedQueue@788375b8
    at kfun:kotlin.Throwable#<init>(kotlin.String?){} + 93 (kotlin/kotlin/Throwable.kt:23:37)
    at kfun:kotlin.Exception#<init>(kotlin.String?){} + 91 (kotlin/kotlin/Exceptions.kt:23:44)
    at kfun:kotlin.RuntimeException#<init>(kotlin.String?){} + 91 (kotlin/kotlin/Exceptions.kt:34:44)
    at kfun:kotlin.native.concurrent.InvalidMutabilityException#<init>(kotlin.String){} + 91 (kotlin/kotlin/native/concurrent/Freezing.kt:22:60)
    at ThrowInvalidMutabilityException + 690 (kotlin/kotlin/native/concurrent/Internal.kt:92:11)
    at MutationCheck + 108
    at kfun:kotlinx.coroutines.sync.MutexImpl.LockedQueue.<set-owner>#internal + 102 (sync/Mutex.kt:350:19)
    at kfun:kotlinx.coroutines.sync.MutexImpl#unlock(kotlin.Any?){} + 3740 (sync/Mutex.kt:327:29)
    at kfun:MutexInvalidMutabilityTest.$doTest$lambda-2$lambda-0COROUTINE$0.invokeSuspend#internal + 2206 (MutexInvalidMutabilityTest.kt:16:61)
    ...

You can find the full code and full stack trace it in this gist: https://gist.github.com/ntherning/a1bf85d44a5989d66677762c15587552 Is this expected behavior? Perhaps I am doing something stupid? Or a bug in

MutexImpl

?