Version 1.6.1 #3232
Merged
Version 1.6.1 #3232
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
…deprecated Gradle dependency declarations (#3088)
Co-authored-by: dkhalanskyjb <[email protected]>
* Make multithreadingSupported a property with a getter This change fixes an issue with the initialization order observed when lazy initialization is disabled (-Xir-property-lazy-initialization= disabled compiler flag) and the new MM is used. The problem is the following: the initialization of DefaultDelay happens before the initialization of multithreadingSupported. Thus the initialization of DefaultDelay gets an uninitialized value of multithreadingSupported and behaves as if the old MM is used. Related issue: #KT-50491.
The approach from 1.6.0 has proven itself as unstable and multiple hard-to-understand bugs have been reported:
* JavaFx timer doesn't really work outside the main thread
* The frequent initialization pattern "runBlocking { doSomethingThatMayCallDelay() }" used on the main thread during startup now silently deadlocks
* The latter issue was reported both by Android and internal JB Compose users
* The provided workaround with system property completely switches off the desired behaviour that e.g. Compose may rely on, potentially introducing new sources of invalid behaviour
The original benefits does not outweigh these pitfalls, so the decision is to revert this changes in the minor release
Fixes #3113
Fixes #3106
Instead of allocating an array of maxPoolSize (~2M) elements for the worst-case supported scenario that may never be reached in practice and takes considerable memory, allocate just an array of corePoolSize elements and grow it dynamically if needed to accommodate more workers. The data structure to make it happen must support lock-free reads for performance reasons, but it is simple since the workers array is modified exclusively under synchronization.
Leverage the fact that `FutureCallback<T>.onSuccess` can only accept `null` when `T` is `null`, to remove the unchecked casts.
… but still keep the pattern of the load roughly the same (#3147)
#3155) * Confine context-specific state to the thread in UndispatchedCoroutine in order to avoid state interference when the coroutine is updated concurrently. Concurrency is inevitable in this scenario: when the coroutine that has UndispatchedCoroutine as its completion suspends, we have to clear the thread context, but while we are doing so, concurrent resume of the coroutine could've happened that also ends up in save/clear/update context Fixes #2930
* Update Dokka to 1.6.10
* Update Kover to 0.5.0 * Update robolectric to workaround robolectric/robolectric#5456 and then workaround all the update consequences
…low (#3185) The details on how buffering conceptually works and what happens without subscribers are buried deep inside the SharedFlow docs. This clarification puts the important information right into the doc of emit and tryEmit methods. Co-authored-by: dkhalanskyjb <[email protected]>
#3199) * Properly cleanup completion in SafeCollector to avoid unintended memory leak that regular coroutines (e.g. unsafe flow) are not prone to Also, FieldWalker is improved to avoid "illegal reflective access" Fixes #3197 Co-authored-by: Roman Elizarov <[email protected]>
Updates the section "Coroutines are light-weight" to clarify its comparison of the resource-intensiveness of coroutines and threads. The content is much the same. This commit also makes the code sample in this section runnable and omits the surrounding runBlocking block.
… not meant to be a public mechanism (#3228)
The initial implementation predates new memory model and was never working on it Fixes #3223
dkhalanskyjb
reviewed
Apr 1, 2022
dkhalanskyjb
approved these changes
Apr 2, 2022
New approach eagerly copies corresponding elements to avoid accidental top-level reuse and also provides merge capability in case when an element is being overwritten. Merge capability is crucial in tracing scenarios to properly preserve the state of linked thread locals Co-authored-by: dkhalanskyjb <[email protected]>
qwwdfsad
force-pushed
the
version-1.6.1
branch
3 times, most recently
from
25328ec to
8c19245
Compare
dkhalanskyjb
approved these changes
Apr 4, 2022
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.
PTAL, I will use this changelog for the release when #3227 is merged (I'll rebase it over develop)