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

Merge with parent project #1

Merged
merged 184 commits into from
Mar 18, 2020
Merged

Merge with parent project #1

merged 184 commits into from
Mar 18, 2020

Conversation

circusmagnus
Copy link
Owner

No description provided.

elizarov and others added 30 commits September 5, 2019 08:04
Send operations must ALWAYS help close the channel when they observe
that it was closed before throwing an exception.

Fixes #1419
* Gradle 5.4.1
* AGP 3.5.0
* Migrated to AndroidX
* Updated versions of all dependencies to the most recent ones
* Removed proguard rules
Fixed incorrect usage of Object.await/notify idiom

Fixes #1513
A channel must be "cancelled" to abort both working senders & receivers.

Fixes #1507
We cannot resume closed receives until all receivers are removed from the list.
Consider channel state: head -> [receive_1] -> [receive_2] -> head
 - T1 called receive_2, and will call send() when it's receive call resumes
 - T2 calls close()

Now if T2's close resumes T1's receive_2 then it's receive gets
"closed for receive" exception, but its subsequent attempt to send
successfully rendezvous with receive_1, producing non-linearizable
execution.
…ng it to the out in DebugProbes.dumpCoroutines

Previously it was done intentionally to reduce synchronization window of DebugProbesImpl, but still have a consistent view of the world and to avoid interleaving with other usages of out.

Apparently, applications with a significant amount of coroutines (e.g. Ktor) may spend a lot of time or even experience OOM in DebugProbes.dumpCoroutines. To make it usable in such applications, we dump coroutines incrementally without releasing a lock in DebugProbesImpl (thus significantly increasing synchronization window) while holding a lock on out to still have a continuous dump.

Fixes #1535
    * Allocate SM instance only once for the last flow value
…er to trigger DebugProbes.probeCoroutineCreated

Fixes #1544
…utines launched from within a test constructor

Fixes #1542
* Promote reactive adapters for Flow to stable API
* Promote Publisher<T>.collect to stable API
* Promote rx2 extensions to stable, increase deprecation level for obsolete reactive primitives
The naming for this convenience function is inspired by Continuation.resumeWith.
* onSend/onReceive clauses on the same channel: Instead of
  StackOverflowError we throw IllegalStateException and leave
  the channel in the original state.
* Fix SOE in select with "opposite channels" stress-test. The fix is
  based on the sequential numbering of atomic select operation.
  Deadlock is detected and the operation with the lower sequential
  number is aborted and restarted (with a larger number).

Fixes #504
Fixes #1411
In preparation to native multithreading.
This should prevent successful casts to type SettableFuture, meaning
client code can't access and complete the internal Future without
resorting to reflection..
    * Remove obsolete rx-example module
    * Properly document interoperability with Reactor context
    * Update reactive readme
…els (#1534)


  * Average performance improvement is around 25%
  * API is internal and targeted to specific usage
  * DispatchedTask and DispatchedContinuation are extracted to separate files for better readability and maintainability
  * Ensure ConsumeAsFlow does not retain reference to the last element of the flow with test
mareklangiewicz and others added 29 commits March 4, 2020 17:44
…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.
It doesn't work properly with new JS IR BE because it depends on a really old plugin version
Detect suspendCancellableCoroutine right after suspendCancellableCoroutineReusable within the same state machine and properly cleanup its child handle when its block completes

Fixes #1855
* Enable JS IR backend
* Workaround resolving Gradle metadata in kotlin2js plugin

Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
* Speed-up installed debug probes by splitting global probes lock to RW-lock, guard all state transitions with read lock and all read operations with write lock to guarantee a consistent snapshot
* Prevent IllegalStateException during 'kill -5' command
* Introduce flag to disable creation stacktrace capturing in DebugProbes
* Support proposed changes in JUnit4 rules

Fixes #1379
Fixes #1372
Co-authored-by: Francesco Vasco <fsco_v-github@yahoo.it>
Fixes #1402

Co-authored-by: Francesco Vasco <fsco_v-github@yahoo.it>
JDK9 Flow integration is implemented as thin
wrappers around the Reactive Streams integration.
There was a small mistake in the Readme of kotlinx-coroutines-test. A lateinit variable evaluated to null at the beginning.
…roperly work on Android <= 6.0 that had a bug on a code-path with an empty stacktrace

Fixes #1866
…roperly work on Android <= 6.0 that had a bug on a code-path with an empty stacktrace (#1868)

Fixes #1866
* ReceiveChannel.broadcast shall start lazy coroutine when closed
* Documentation on broadcast operators is added that explains that the resulting BroadcastChannel shall be cancelled if it is not needed anymore.
* The only functional change is that closing a broadcast channel for lazy coroutine shall start the corresponding coroutine to give it a chance to promptly fail.
*  Also fix the order of events in lazy actor to be consistent with a broadcast channel

Fixes #1713
* BlockHound integration for Dispatchers.Default and Dispatchers.IO
* Use JNA-based self-attach mechanism in order to workaround a problem when tools.jar is loader by multiple classloaders
* publication-validator is renamed to integration-testing;
* Each test is now in a separate source set, which allows for more
  flexibility in their configuration; for example, failing to set
  `dryRun=true` doesn't prevent tests other than NPM to run, and
  it is possible to run the tests (and their dependencies)
  separately.
* Add an integration test for coroutine debugger java agent

Fixes #1060
Fixes #1031

Co-authored-by: Vsevolod Tolstopyatov <qwwdfsad@gmail.com>
* Flow firstOrNull support

Co-authored-by: Bradyn Poulsen <bradyn@bradynpoulsen.com>
@circusmagnus circusmagnus merged commit 74d3d60 into circusmagnus:master Mar 18, 2020
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.