Version 1.3.4 #1846
Merged
Version 1.3.4 #1846
Conversation
This file contains 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
This makes site-building process more stable and less dependent on the environment, requiring only Docker to be installed locally.
…m the waiting queue to the buffer
Experimental ReceiveChannel.receiveAsFlow extension convert channel to flow in fan-out fashion allowing for multi-use. * Also, ReceiveChannel.consumeAsFlow is promoted to experimental from preview Fixes #1490
* When using asFlow().flowOn(...) context is now properly tracked and taken into account for both execution context of the reactive subscription and for injection into Reactor context. * Publisher.asFlow slow-path implementation is simplified. It does not sure specialized openSubscription anymore, but always uses the same flow request logic. Fixes #1765
…nts one by one in a default configuration Also, partially masks #1766
`runBlocking` waits for all the threads it spawned to finish, so if `verifyDump` failed in `RunningThreadStackMergeTest.kt`, the tests would just hang: one of the threads would wait for a barrier to break, which would never happen.
Get rid of Hamcrest, which is uncommon in this codebase, and replace as many `assert` statements from other testing frameworks as is reasonable with little automation by calls to `kotlin.test.*`.
…linked list used for suspending receivers only.
* Improve FieldWalker, don't access JDK classes * Works on future JDKs that forbid reflective access to JDK classes * Show human-readable path to field is something fails
An extremely rare race could happen in any of the tests in `LeakedExceptionTest` in the following case: * `withExceptionHandler` runs the block passed to it; * In one of the last iterations of `repeat`, `select` in `combine` happens on both flows at the same time, that is, the block that was passed to `rx[Something]` runs in two threads simultaneously; * One of these two threads (thread A) runs anomalously slow; * The other thread successfully throws an exception; * This exception is propagated to `catch`, so `collect` is finished; * `repeat` is exited, the block passed to `withExceptionHandler` is done executing; * `withExceptionHandler` sets back the usual exception handler, which fails when an exception in JavaRX happens (see https://github.com/ReactiveX/RxJava/wiki/What's-different-in-2.0#error-handling); * Thread A wakes up and throws an exception. This time, it is passed not to `handler`, which is made specifically to deal with this, but to the default handler. As a fix, now a special coroutine context passed to `rx[Something]` ensures that the spawned executions are run in a thread pool that blocks until all the tasks are done.
* Use a separate Knit tool version 0.1.2
* Hierarchical knit.properties files are introduced which are
gathered while walking up the directory tree with the properties
in knit resources being top-level ones.
* Freemarker templates for "knit.include" (top-level of example files)
and "test.template" (test template) are introduced with locations that
are resolved from properties.
* KNIT and TEST_OUT directives are not supported anymore.
- Knitting is controlled by "knit.dir" and "knit.pattern" props.
- "test.name" prop or TEST_NAME directive drives test gen.
* All markdown files are now clean of top-level knit-related boilerplate
(only TEST_NAME directive is remaining in some)
* All example files are renumbered. It affects example-basic-xx,
which had the legacy numbering with later insertions.
* All auto-generated files now have the correct source-file name
specified at their beginning, due to consistent use of template
substitution.
* No need to customize knit.pattern anymore (works out-of-the box)
* "knit.name" is automatically generated based on example's file name
"example-basic-01" -> "exampleBasic01"
* Not match-pattern-group woodoo anymore, "knit.pattern" cannot have any
user-defined match groups.
* No need to look for "package xxx" in knitted sources, as the
example's package is always ${knit.package}.${knit.name}
* Simpler test names:
testKotlinxCoroutinesGuideBasic01 -> testExampleBasic01
* Replaced END_TOC with END directive
* Build-scripts are improved:
- Consistent code to use mavenLocal when snapshots versions are used.
- Proper substitution logic to use Android AAR files so that Dokka has correct links to Google APIs.
- Google repository is added to all projects.
* Support build on both JDK 1.8 & 11, check for publishing under JDK 11 * Up the Robolectric version to support JDK11. According to robolectric/robolectric#4085, by 4.0.2 it should support JDK11. Tests do pass after setting the version to 4.0.2, but they fail for every version released after that up to 4.3.1. It is unclear what causes this. I commit this to check how it works on the build agents, as some comments in the issue imply that on MacOS this version, too, does not work with JDK11. * Fix fully qualified names in stacktraces in tests: - With move to JDK11, the `park` method changed its fully qualified name. * Add new sanitazing to verification of stacktraces: - Now stacktraces have additional substrings, separated by a slash: java-base/java.util.lang - They are stripped away. - Also, the placement of tabs has changed, and so the tabs are also completely removed. * Refactor `verifyStackTrace` - It used to wrap the only loop where something happened in two other loops that did nothing. Now, only the innermost loop is left. * Use a separate JavaFx dependency. * Improve error handling for JavaFX initialization - Now, the JavaFX initialization may fail with an exception in case something went wrong. - The driver for this change was that the initialization started hanging in headless environments with transition to JDK 11. - Before, the initialization logic had a flaw. If a call to one API failed, another API would be attempted. However, this approach is problematic: if the first call failed with an exception for some reason, it would leave JavaFX in a broken state where a flag would imply that the system is being initialized. Subsequent calls would then proceed to wait forever for the initialization to complete. - Now, exceptions are checked more carefully, ensuring that we only fall back to the internal API in case the public one is unavailable and not failed for some valid reason. This differentiation also allows to more boldly rethrow exceptions upwards, being more or less confident that these are relevant to the user. * Additionally test JavaFX integration with JDK8 Co-authored-by: Dmitry Khalanskiy <dmitry.khalanskiy@jetbrains.com> Co-authored-by: Roman Elizarov <elizarov@gmail.com>
* Includes additional R8 rules to disable debugging & stack-trace recovery in optimized Android builds. Additional savings with AGP 4.0.0-alpha06 (r8-2.0.4-dev) are ~16kb in uncompressed DEX size. * Tests are modified to verify that the classes that are supposed to be removed are indeed removed. * Cleaner build logic without error-prone "return" in the middle * Report the size of optimized Android Dex as teamcity metric
Before, publication validator was just lying nearby, in these files, and built and run separately. Now, it is compiled alongside the main project (in the `test` gradle configuration), so its breakage will be detected during normal usage. Still, it is only run when a special gradle property, `DeployVersion`, is defined.
* atomicfu version 0.14.2
Lock-free list implementation is considerably simplified, taking into account a limited number of operations that it needs to support. * prev pointers in the list are not marked for removal, since we don't need to support linearizable backwards iteration. * helpDelete method is completely removed. All "delete-helping" is performed only by correctPrev method. * correctPrev method bails out when the node it works on is removed to reduce contention during concurrent removals. * Special open methods "isRemoved" and "nextIfRemoved" are introduced and are overridden in list head class (which is never removed). This ensures that on long list "removeFist" operation (touching head) does not interfere with "addLast" (touch tail). There is still sharing of cache-lines in this case, but no helping between them. All in all, this improvement reduces the size of implementation code and makes it considerably faster. Operations on LinkedListChannel are now much faster (see timings of ChannelSendReceiveStressTest).
* Implement ObservableValue<T>.asFlow() Fixes #1695
…st (#1845) * The problem was introduced by #1565. When doing concurrent add+removeFirst the following can happen: - "add" completes, but has not correct prev pointer in next node yet - "removeFirst" removes freshly added element - "add" performs "finishAdd" that adjust prev pointer of the next node and thus removed element is pointed from the list again * A separate LockFreeLinkedListAddRemoveStressTest is added that reproduces this problem. * The old LockFreeLinkedListAtomicLFStressTest is refactored a bit.
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.