Version 1.7.0-Beta #3667
Merged
Version 1.7.0-Beta #3667
Conversation
This file contains hidden or 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
Co-authored-by: mvicsokolova <[email protected]>
* Mark context in DiagnosticCoroutineContextException as transient Fixes #3328
* Get rid of the old Kotlin/Native memory model Fixes #3375
* Introduce Job.parent API * The API is crucial for debugger extension and deadlock detection * It enables allows more fluent coroutines hierarchy inspection, e.g. capability to build a list of roots and procrss them top-bottom separately Fixes #3201
* New selects are twice as fast as the previous version * The implementation doesn't require an NCAS protocol by giving up lock-freedom and linearizability in corner cases * The overall algorithm is much more straightforward and easier to maintain Co-authored-by: Nikita Koval <[email protected]>
… primitives (#3391) It should further simplify reasoning about new fields in core classes
Otherwise, usage of withTimeout lead to excessive memory pressure and OOMs
* The correctness of the change is verified by ConsumeAsFlowLeakTest * Follow-up cleanup here and there
… … (#3438) * Reduce hand-rolled ArrayQueue with ArrayDeque in standard library in order to (potentially) reduce dex size
* Fix for integration-testing:mavenTest: exclude metadata when checking classes bytecode for ATOMIC_REF * Moved SegmentBasedQueue implementation to the main module * Removed SegmentListTest
…te (#3393) * Introduce non-nullable types in reactive integrations where appropriate * For RxJava2, use them in internal implementations where appropriate * For RxJava3, introduce & Any bound to a generic argument in our extensions to avoid errors in Kotlin 1.8.0 due to non-nullability rx3 annotations being part of generics upper bound. This change went through committee, and all the "unsound" declarations such as "RxSignature<Foo?>" were properly highlighted as a warning that would become an error.
* Also, add tests that verify our disabled assertions * Fix nullability in AgentPremain that used to work by accident (because we disabled those assertions) * Fix all corresponding warnings Co-authored-by: Dmitry Khalanskiy <[email protected]>
* Emulate expect declaration refinement via extension property as the only way to do it in a backwards-compatible manner: in the current model, it is impossible to have common 'expect' Dispatchers declaration, then refined 'concurrent' Dispatchers declaration with 'expect val IO' and then JVM declaration with JVM-specific members. Current solutions seems to be the less intrusive one Fixes #3205
… contexts with no job in it. (#3639) Otherwise, the API is becoming an error prone for being called from jobless entrypoints (i.e. 'suspend fun main' or Ktor handlers), as 'if (ctx.isActive)' is a well-established pattern for busy-wait or synchronous job. It is now aligned with CoroutineScope.isActive behaviour. Fixes #3300
When when a `Job` doesn't have a parent, failures in it can not be reported via structured concurrency. Instead, the mechanism of unhandled exceptions is used. If there is a `CoroutineExceptionHandler` in the coroutine context or registered as a `ServiceLoader` service, this gets notified, and otherwise, something platform-specific happens: on Native, the program crashes, and on the JVM, by default, the exception is just logged, though this is configurable via `Thread.setUncaughtExceptionHandler`. With tests on the JVM, this is an issue: we want exceptions not simply *logged*, we want them to fail the test, and this extends beyond just coroutines. However, JUnit does not override the uncaught exception handler, and uncaught exceptions do just get logged: <https://stackoverflow.com/questions/36648317/how-to-capture-all-uncaucht-exceptions-on-junit-tests> This is a problem with a widely-used `viewModelScope` on Android. This is a scope without a parent, and so the exceptions in it are uncaught. On Android, such uncaught exceptions crash the app by default, but in tests, they just get logged. Clearly, without overriding the behavior of uncaught exceptions, the tests are lacking. This can be solved on the test writers' side via `setUncaughtExceptionHandler`, but one has to remember to do that. In this commit, we attempt to solve this issue for the overwhelming majority of users. To that end, when the test framework is used, we collect the uncaught exceptions and report them at the end of a test. This approach is marginally less robust than `setUncaughtExceptionHandler`: if an exception happened after the last test using `kotlinx-coroutines-test`, it won't get reported, for example. `CoroutineExceptionHandler` is designed in such a way that, when it is used in a coroutine context, its presence means that the exceptions are safe in its care and will not be propagated further, but when used as a service, it has no such property. We, however, know that our `CoroutineExceptionHandler` reports the exceptions properly and they don't need to be further logged, and so we had to extend the behavior of mechanism for uncaught exception handling so that the handler throws a new kind of exception if the exception was processed successfully. Also, because there's no `ServiceLoader` mechanism on JS or Native, we had to refactor the whole uncaught exception handling mechanism a bit in the same vein as we had to adapt the `Main` dispatcher to `Dispatchers.setMain`: by introducing internal setter APIs that services have to call manually to register in. Fixes #1205 as thoroughly as we can, given the circumstances.
…Segment`s (#3084) * This optimization enables allocation-free channel operations, as we no longer have to allocate a cancellation handler for suspending channel operations * Add a sequential semaphore benchmark and a generalized version of `ChannelSinkBenchmark` that supports buffered channels and pre-allocates elements to isolate the effect Signed-off-by: Nikita Koval <[email protected]> Co-authored-by: Vsevolod Tolstopyatov <[email protected]>
#3634) * Release reusability token when suspendCancellableCoroutineReusable's block throws an exception Otherwise, the continuation instance is left in REUSABLE_CLAIMED state that asynchronous resumer awaits in an infinite spin-loop, potentially causing deadlock with 100% CPU consumption. Originally, the bug was reproduced on an old (pre-#3020) implementation where this very pattern was encountered: it was possible to fail the owner's invariant check right in the supplied 'block'. This is no longer the case, so the situation is emulated manually (but still is possible in production environments, e.g. when OOM is thrown). Also, suspendCancellableCoroutineReusable is removed from obsolete BroadcastChannel implementation. Fixes #3613
* Add module-info.java processing task to remove the `kotlinx-atomicfu` dependency * Remove module-info.java filter as it's actually no-op * Cleanup imports in Java9Modularity * Fix configuration cache issue in compileModuleInfoJava Co-authored-by: Alexander.Likhachev <[email protected]>
…spatcher #3641) * Added internal API to run both Dispatchers.Default and Dispatchers.IO * Added internal API to check whether the current thread is IO * Reworked WorkQueue API to have the concept of polling and stealing in "exclusive" modes for the sake of these APIs Fixes #3439 Co-authored-by: Dmitry Khalanskiy <[email protected]>
The timeout was too low, the test body would never get a chance to run.
dkhalanskyjb
reviewed
Mar 8, 2023
dkhalanskyjb
reviewed
Mar 8, 2023
qwwdfsad
force-pushed
the
version-1.7.0-Beta
branch
from
ff0e132 to
f7824a2
Compare
qwwdfsad
force-pushed
the
version-1.7.0-Beta
branch
from
f7824a2 to
a3060c6
Compare
dkhalanskyjb
approved these changes
Mar 8, 2023
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.