Skip to content
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

Version 1.6.1 #3232

merged 30 commits into from Apr 4, 2022

Version 1.6.1 #3232

merged 30 commits into from Apr 4, 2022


Copy link

@qwwdfsad qwwdfsad commented Apr 1, 2022

PTAL, I will use this changelog for the release when #3227 is merged (I'll rebase it over develop)

severn-everett and others added 27 commits Jan 10, 2022
Co-authored-by: dkhalanskyjb <>
* 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)

* 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
…he original exception prior to passing it to the Thread.currentThread().uncaughtExceptionHandler() (#3170)

Fixes #3153
* 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 <>

* 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 <>
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.
The initial implementation predates new memory model and was never working on it

Fixes #3223
@qwwdfsad qwwdfsad requested a review from dkhalanskyjb Apr 1, 2022 Outdated Show resolved Hide resolved Outdated Show resolved Hide resolved Outdated Show resolved Hide resolved Outdated Show resolved Hide resolved Outdated Show resolved Hide resolved
@qwwdfsad qwwdfsad requested a review from dkhalanskyjb 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 <>
@qwwdfsad qwwdfsad force-pushed the version-1.6.1 branch 3 times, most recently from 25328ec to 8c19245 Compare Apr 4, 2022
@qwwdfsad qwwdfsad merged commit 2c3435c into master Apr 4, 2022
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging this pull request may close these issues.

None yet