Skip to content

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
wants to merge 98 commits into from
Closed

Doc/deferred #3643

wants to merge 98 commits into from

Conversation

tommus
Copy link
Contributor

@tommus tommus commented Feb 26, 2023

This pull request simply removes duplicated "be" verb from Deferred kdoc.

qwwdfsad and others added 30 commits July 14, 2022 16:26
…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]>
dkhalanskyjb and others added 26 commits January 17, 2023 14:13
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.
@tommus tommus closed this Feb 26, 2023
@tommus
Copy link
Contributor Author

tommus commented Feb 26, 2023

Closed due to the fact I've selected wrong target branch in my previous pull request. I kindly apologize for the mistake.

@dkhalanskyjb
Copy link
Collaborator

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 master directly, since it only changes the docs without affecting the line numbers.

@tommus tommus deleted the doc/deferred branch February 26, 2023 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.