-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Doc/deferred #3643
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Doc/deferred #3643
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]>
…lin#3370) * Mark context in DiagnosticCoroutineContextException as transient Fixes Kotlin#3328
* Get rid of the old Kotlin/Native memory model Fixes Kotlin#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 Kotlin#3201
… avoid race with original thread setting parent handle, while another thread nulls it out during cancellation via detachChild (Kotlin#3380) Fixes one of the races found in Kotlin#3378
* 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 (Kotlin#3391) It should further simplify reasoning about new fields in core classes
…lin#3440) 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
… … (Kotlin#3438) * Reduce hand-rolled ArrayQueue with ArrayDeque in standard library in order to (potentially) reduce dex size
…3455) * Fix for integration-testing:mavenTest: exclude metadata when checking classes bytecode for ATOMIC_REF * Moved SegmentBasedQueue implementation to the main module * Removed SegmentListTest
…te (Kotlin#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.
…#3466) * 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]>
Kotlin#3593) * Remove ThreadLocal from ThreadLocalMap when finishing UndispatchedCoroutine * It addresses the problem with ThreadLocalMap.entries that may outlive the coroutine lifecycle and interfere with CPU consumption of other thread-locals on the same thread * No test provided as this is a non-functioanl change. The only reasonable way to check it is to reflectively walk over Thread class which is prohibited by Java since 11+. The only way is to eyeball Thread.currentThread().threadLocals size in debugger in the properly crafted unit test * Do not touch thread-locals if they were never set in UndispatchedCoroutine Fixes Kotlin#3592
* Get rid of RW lock that was contended enough on reads to be observable by non-concurrent coroutines-heavy code (up to 30% of throughput on IDEA-specific benchmark) * Tweak the code to be DRF in the absence of RW lock * Document snapshots' weak consistency guarantee Fixes Kotlin#3527
…in#3614) We update the docs in Dispatchers.common.kt, but JVM's Dispatchers.kt also has its own version of it, which is accessible via the "JVM" tab of the docs: <https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/-dispatchers/-unconfined.html> The docs there are outdated, so we remove them.
### Reproducing scenario For the following code: ``` suspend fun foo() = yield() ``` the following bytecode is produced: ``` fun foo(...) { uCont.intercepted().dispatchUsingDispatcher() // 1 probeCoroutineSuspended() // 2 return COROUTINE_SUSPENDED // Unroll the stack } ``` And it is possible to observe the next 'probeCoroutineSuspended' **prior** to receiving 'probeCoroutineSuspended'. ### Steps taken To address this, a dedicated 'unmatchedResumes' field is introduced to the coroutine state, which keeps track of consecutive 'probeCoroutineResumed' without matching 'probeCoroutineSuspended' and attributes lately arrived probes to it. Unfortunately, it introduces a much more unlikely race when **two** 'probeCoroutineSuspended' are reordered, then we misattribute 'lastObservedFrame', but it is still better than misattributing the actual coroutine state. @volatile and @synchronized are also introduced to DebugCoroutineInfoImpl as previously they have been subject to data races as well Fixes Kotlin#3193
See Kotlin#3621 for detailed description and rationale Fixes Kotlin#3621
…arties (Kotlin#3396) Fixes Kotlin#3395 by capturing the stack frames for both the reader+writer and the writer+writer cases
* 'inline' modifier is removed from 'findSegmentInternal'. It previously lead to KT-55983: incorrect SMAP was produced that crashed the debugger consistently * Non-inline functions are non-capturing, thus no additional performance overhead * Method-reference is extracted to a variable in few places as it were crashing JVM compiler with AIOOB consistently
…is detected (Kotlin#3620) * Behaviour compatible with the previous implementation is restored * For everything else, there is Kotlin#3626 Signed-off-by: Nikita Koval <[email protected]> Co-authored-by: Nikita Koval <[email protected]>
Kotlin#3624) * Remove dead-code in the LockFreeLinkedList implementation after new channels implementation * Slightly speedup the build without unnecessary stress-tests * Get rid of dead-code that was used only by channels, so it's easier to reason about JobSupport implementation * Slightly cut dex size in the face of new channels regression as LFLL is no longer shared between JobSupport and Channel
* Compiles hand-written module-info.java into Multi-Release JAR for all modules Contributed by @lion7 Fixes Kotlin#2237 Co-authored-by: Gerard de Leeuw <[email protected]>
Deprecate `dispatchTimeoutMs`, as this is a confusing implementation detail that made it to the final API. We use the fact that the `runTest(Duration)` overload was never published, so we can reuse it to have the `Duration` mean the whole-test timeout in a backward-compatible manner.
* 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 Kotlin#3205
… contexts with no job in it. (Kotlin#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 Kotlin#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 Kotlin#1205 as thoroughly as we can, given the circumstances.
Closed due to the fact I've selected wrong target branch in my previous pull request. I kindly apologize for the mistake. |
Don't worry, this repository constantly sees much worse things than a misplaced base: see #3610. Also, it would even be okay for that change to go to |
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.
This pull request simply removes duplicated "be" verb from
Deferred
kdoc.