Update core coroutines #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We cannot resume closed receives until all receivers are removed from the list. Consider channel state: head -> [receive_1] -> [receive_2] -> head - T1 called receive_2, and will call send() when it's receive call resumes - T2 calls close() Now if T2's close resumes T1's receive_2 then it's receive gets "closed for receive" exception, but its subsequent attempt to send successfully rendezvous with receive_1, producing non-linearizable execution.
…sts to ensure its contract Addresses #1527
…ng it to the out in DebugProbes.dumpCoroutines Previously it was done intentionally to reduce synchronization window of DebugProbesImpl, but still have a consistent view of the world and to avoid interleaving with other usages of out. Apparently, applications with a significant amount of coroutines (e.g. Ktor) may spend a lot of time or even experience OOM in DebugProbes.dumpCoroutines. To make it usable in such applications, we dump coroutines incrementally without releasing a lock in DebugProbesImpl (thus significantly increasing synchronization window) while holding a lock on out to still have a continuous dump. Fixes #1535
* Allocate SM instance only once for the last flow value
…er to trigger DebugProbes.probeCoroutineCreated Fixes #1544
…utines launched from within a test constructor Fixes #1542
* Promote reactive adapters for Flow to stable API * Promote Publisher<T>.collect to stable API * Promote rx2 extensions to stable, increase deprecation level for obsolete reactive primitives
The naming for this convenience function is inspired by Continuation.resumeWith.
* onSend/onReceive clauses on the same channel: Instead of StackOverflowError we throw IllegalStateException and leave the channel in the original state. * Fix SOE in select with "opposite channels" stress-test. The fix is based on the sequential numbering of atomic select operation. Deadlock is detected and the operation with the lower sequential number is aborted and restarted (with a larger number). Fixes #504 Fixes #1411
In preparation to native multithreading.
This should prevent successful casts to type SettableFuture, meaning client code can't access and complete the internal Future without resorting to reflection..
…lete reactive primitives
* Remove obsolete rx-example module
* Properly document interoperability with Reactor context
* Update reactive readme
…els (#1534) * Average performance improvement is around 25% * API is internal and targeted to specific usage * DispatchedTask and DispatchedContinuation are extracted to separate files for better readability and maintainability * Ensure ConsumeAsFlow does not retain reference to the last element of the flow with test
Version 1.3.2
# Conflicts: # reactive/kotlinx-coroutines-reactive/src/Channel.kt # reactive/kotlinx-coroutines-rx2/src/RxChannel.kt
* Use standard random API * Inline 'random' method
* Fix code formatting in doc example and make it more concise (both vertically and horizontally). * Don't promote custom `withTimeout` logic in examples. Use the actual `withTimeout` function. * Logical introduction of `context` parameter in docs (first use without it, then explain how it helps), consistent doc references. * Improved implementation in various places: * runInterruptibleInExpectedContext does not have to be suspend * There is always Job in the context * ThreadState should not do complex init in constructor (that's bad style) * ThreadState does not need inner State class, atomic int is enough * Consistent project-wide variable naming: state -> _state * Consistent use of `error` function to throw IllegalStateException
Spell-check & subject/body separation inspection
StateFlow is a Flow analogue to ConflatedBroadcastChannel. Since Flow API is simpler than channels APIs, the implementation of StateFlow is simpler. It consumes and allocates less memory, while still providing full deadlock-freedom (even though it is not lock-free internally). Fixes #1973 Fixes #395 Fixes #1816 Co-authored-by: Vsevolod Tolstopyatov <[email protected]>
Version 1.3.6
* Using Kotlin official style * Start imports for all packages * Continuation indent size = 4
* Restore java configuration for 'benchmarks' * Apply 'jmh' plugin after java configuration * Specify java.util.concurrent imports after migration to Java 11 * Remove duplicated dependency * Use release version of 'jmh' plugin. '0.5.0-rc-2' -> '0.5.0'
#2010) Co-authored-by: zhouxin <[email protected]>
…withContext, runBlocking, withTimeout and select (#2030)
Make Flow more cancellation friendly:
* flow builder is cancellable by default
* New unambiguous currentCoroutineContext top-level function
* New Flow.cancellable() operator
Fixes #2026
* A more consistent prose in the Job interface documentation, gradually explaining concepts without repetition. * Clear introduction and naming of "coroutine job" vs "completable job". * Explanation of what is a "cancellation cause" of Job and how that relates to CancellationException. * Added a note to all Job-derived interfaces that they are not safe for inheritance in 3rd party libraries. * Consistently copied a note on thread-safety to all job-derived interfaces.
Version 1.3.7
Co-authored-by: Louis CAD <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.