Version 1.3.3 #1703
Merged
Version 1.3.3 #1703
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
Send operations must ALWAYS help close the channel when they observe that it was closed before throwing an exception. Fixes #1419
* Gradle 5.4.1 * AGP 3.5.0 * Migrated to AndroidX * Updated versions of all dependencies to the most recent ones * Removed proguard rules
Fixed incorrect usage of Object.await/notify idiom Fixes #1513
A channel must be "cancelled" to abort both working senders & receivers. Fixes #1507
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..
…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
# Conflicts: # reactive/kotlinx-coroutines-reactive/src/Channel.kt # reactive/kotlinx-coroutines-rx2/src/RxChannel.kt
* ./gradlew :kotlinx-coroutines-core:jvmTest becomes really fast, since it does not run any stress tests. * ./gradlew build still runs all the tests.
This bug was introduced by #1524. The crux of problem is that TryOffer/PollDesc.onPrepare method is no longer allowed to update fields in these classes (like "resumeToken" and "pollResult") after call to tryResumeSend/Receive method, because the latter will complete the ongoing atomic operation and helper method might find it complete and try reading "resumeToken" which was not initialized yet. This change removes "pollResult" field which was not really needed ("result.pollResult" field is used) and removes "resumeToken" by exploiting the fact that current implementation of CancellableContinuationImpl does not need a token anymore. However, CancellableContinuation.tryResume/completeResume ABI is left intact, because it is used by 3rd party code. This fix lead to overall simplification of the code. A number of fields and an auxiliary IdempotentTokenValue class are removed, tokens used to indicate various results are consolidated, so that resume success is now consistently indicated by a single RESUME_TOKEN symbol. Fixes #1561
They return Symbol?
Was failing with java.lang.AssertionError at kotlinx.coroutines.channels.SendElement.tryResumeSend(AbstractChannel.kt:1055) at kotlinx.coroutines.channels.AbstractChannel.pollInternal(AbstractChannel.kt:510) at kotlinx.coroutines.channels.AbstractChannel.receive(AbstractChannel.kt:548)
… in Flow.reduce
* We can do it safely because reduce is still experimental
* We will be consistent with stdlib (as soon as KT-33874 is implemented)
* We cannot allow emitting elements when downstream exception occurred, otherwise it may lead to a weird side-effects when "collect" block (or any other terminal operator) has thrown an exception, but keeps receiving new values
* Another solution may be to silently ignore emitted values, but it may lead to a postponed cancellation and surprising behaviour for users
Fixes #1654
…tegrations Use tryOnError in RxJava to make exception delivery check-and-act race free. Deliver undeliverable exceptions via RxJavaPlugins instead of handleCoroutineException. This is a deliberate choice for a multiple reasons: * When using Rx (whether with coroutines or not), undeliverable exceptions are inevitable and users should hook into RxJavaPlugins anyway. We don't want to force them using Rx-specific CoroutineExceptionHandler all over the place * Undeliverable exceptions provide additional helpful stacktrace and proper way to distinguish them from other unhandled exceptions * Be consistent with reactor where we don't have try*, thus cannot provide a completely consistent experience with CEH (at least, without wrapping all the subscribers)\ Do the similar in Reactor integration, but without try*, Reactor does not have notion of undeliverable exceoptions and handles them via Operators.* on its own. Also, get rid of ASCII tables that are not properly render in IDEA Fixes #252 Fixes #1614
…CoroutineScheduler
* WorkQueue.trySteal reports not only whether the steal was successful, but also a waiting time unless task becomes stealable
* CoroutineScheduler.trySteal attempts to steal from all the workers (starting from the random position) per iteration to have deterministic stealing
* Parking mechanics rework. After unsuccessful findTask, worker immediately adds itself to parking stack, then rescans all the queues to avoid missing tryUnparks and only then parks itself (parking duration depends on WorkQueue.trySteal result), terminating later
* Excessive spinning and parking is completely eliminated, significantly (x3) reducing CPU-consumption and making CoroutineScheduler on-par with FJP and FTP on Ktor-like workloads
* Downside of aggressive parking is a cost of slow-path unpark payed by external submitters that can be shown in degraded DispatchersContextSwitchBenchmark. Follow-up commits will fix that problem
* Retry on tryStealLastScheduled failures to avoid potential starvation
* Merge available CPU permits with controlState to simplify reasoning about pool state and make all state transitions atomic
* Get rid of synthetic accessors
* Work stealing: get rid of global queue for offloading during stealing because it never happens in fact
* Guard all critical invariants related to work-stealing with asserts
* New work signalling strategy that guarantees complete liveness in the face of "accidentally-blocking" CPU tasks
* Advanced double-phase unparking mechanism that mitigates the most expensive part of signalling an additional work
* Current limitation: blocking tasks are not yet properly signalled
Invariants:
* Steal only one task per attempt to avoid missing steals that potentially may block the progress (check-park-check may miss tasks that are being stolen)
* New WorkQueue.add invariant: bufferSize < capacity => add is always successful
* Re-visited tests that expose a lot of problems
* Ability to steal from the middle of work queue in order to steal blocking tasks with ABA prevention
Changes:
* Instead of "blocking workers" use "blocking tasks" state that is incremented on each blocking submit and decrement only when task is completed
* On each work signalling try to compensate blocking tasks by enforcinf invariant "created threads == blocking tasks + up to core size workers"
* Now if worker was not spuriously woken up, it has a task dedicated for him that should be found. For that reason attempt to steal blocking tasks
(that may be in the middle of the work queue). Additionally, instead of scanning the whole global queue, just split it in two (one for blocking, one for regular tasks)
* Get rid of conditional remove from the global queue
* Avoid excessive unparks for threads that are not yet able to steal the task due to workstealing resolution: do not add such workers to the stack
* Do not push worker to the stack during second pass of "min duration scanning"
* Locally cache whether local queue has any work to execute to save atomic getAndSet and a bunch of atomic loads
* More precise rendezvous for parking
* Long-scanning stealing to emulate spinning
* Properly handle interference of termination sequence and protection against spurious wakeups
* Documentation improvements, naming, proper spurious wakeup check
…et rid of long-scanning sequence
# Conflicts: # docs/flow.md
0b6745e
to
2489b34
Compare
2489b34
to
efc234f
Compare
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.