#1728)

Do not request additional worker from 'yield' calls and during post-execution phase in LimitingDispatcher

Fixes #1704
Fixes #1706

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

…uilds (KT-11567)

…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.*`.

Fixes #1797

…linked list used for suspending receivers only.

#1771)


Fixes #1762
Fixes #1770

* 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

#1793)

  
* Make SafeCollector platform-specific declaration and enforce exception transparency invariant on JVM
    * Make it in an allocation-free manner by using a crafty trick with casting KSuspendFunction to Function and pass a reusable object as a completion

Fixes #1657

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.

…1795)

* 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.

See https://youtrack.jetbrains.com/issue/KT-36776

…o ensure proper termination, including finally blocks and onCompletion operators (#1829)

Fixes #1825

* 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

…eDispatcher (#1840)

…g message (#1842)

…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.