kotlinx.coroutines
kotlinx.coroutines copied to clipboard
Kotlin
Library support for Kotlin coroutines
In normal coroutine cases, all things occured in `async{}` block should be confined in the returned Deferred object, and let the caller to determine the futher usage, such as calling...
On current moment, looks like there is no way to safely pass resources through Flow. Like f.e. files, or buffers, as if cancellation appears somewhere during `emit`, resource will be...
Our team has started using kotlin-coroutines-rx2 to incrementally migrate our codebase from RxJava2 to coroutines. In so doing, we encounter a lot of call sites like the following: ```kotlin disposables...
`Dispatchers.IO` is only available for Kotlin/JVM according to [the docs](https://kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-i-o.html). It would be great to have this available on Kotlin/Native, as this would make it easier to share code between...
A coroutine object's toString() debug output is sometimes a bit too much info. It would be useful to be able to access more fine-grained coroutine info for the sake of...
Investigate possible shortcuts for `coroutineContext.job.invokeOnCompletion { if (it != null) ... }`
The pattern itself is useful for any closeable resources that face non-atomic cancellation (https://github.com/Kotlin/kotlinx.coroutines/issues/1191) as the only reliable way to close it. Apart from that, the pattern itself is very...
Currently, the machinery of coroutines have two code-paths: * Dispatcheable coroutines that have `ContinuationInteceptor` being an instance of `CoroutineDispatcher` in their context. From implementation standpoint, implementation [checks](https://github.com/Kotlin/kotlinx.coroutines/blob/master/kotlinx-coroutines-core/common/src/CancellableContinuationImpl.kt#L517) ([one more example...
The Kotlin stdlib provides `filterIsInstance` for Array and Iterable with an inline and non inline version (aka with Class). Flow does not include the Class version. This seems inconsistent and...
Note: depends on kotlinx.atomicfu ARM builds (PR for support here: https://github.com/Kotlin/kotlinx.atomicfu/pull/193 )
