-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Version 1.5.0-RC #2675
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
Merged
Merged
Version 1.5.0-RC #2675
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
`kotlinx.coroutines.debug.internal.DebugProbesImpl.updateState` sometimes parks in order to acquire a lock, which leads BlockHound to detect an illegal blocking call. Now, blocking calls inside `DebugProbesImpl` are permitted. Though allowing `updateState` would suffice, the other users of the lock seem safe, too, and are allowed even when it doesn't make much sense to call them from coroutines.
They were deprecated long time ago and were removed in Gradle 7
* It slightly cuts down startup time * It simplifies the code in general * It do not serve its purpose, coroutines are already protected from StackOverflowError with nested event-loops where applicable
* Update Gradle to 4.8.3, add space-dev repository * Update atomicfu and binary compatibility validator
* Merge onStartInternal and onStart to reduce the number of methods and make code a bit simpler * Rework initParentJob * Always establish a parent-child relationship when creating a subclass of AbstractCoroutine. That's our own internal class that we have full control of and it never has a chance to leak to the user-code (so cancellation handlers will be installed etc.). Force implementors of AbstractCoroutine deliberately choose whether parent-child relationship should be established * As a consequence, get rid of parentContext in all our coroutine classes that are not ScopeCoroutine * Remove some dead code * Get rid of an additional parent field from ScopeCoroutine Leverage already presented information in our implementation, just expose it via an already present internal interface
* Update SharedFlow documentation
* Rework reusability control in cancellable continuation * Update initCancellability documentation and implementation to be aligned with current invariants * Make parentHandle non-volatile and ensure there are no races around it * Establish new reusability invariants - Reusable continuation can be used _only_ if it states is not REUSABLE_CLAIMED - If it is, spin-loop and wait for release - Now the parent is attached to reusable continuation only if it was suspended at least once. Otherwise, the state machine can return via fast-path and no one will be able to release intercepted continuation (-> detach from parent) - It implies that the parent is attached after trySuspend call and can be concurrently reused, this is where new invariant comes into play * Leverage the fact that it's non-atomic and do not check it for cancellation prematurely. It increases the performance of fast-path, but potentially affects rare cancellation cases Fixes #2564
* Introduce three-state ChannelResult, a domain-specific Result class counterpart * Introduce receiveCatching/onReceiveCatching, make it public * Get rid of receiveOrClosed/onReceiveOrClosed without migrations, it was @InternalCoroutinesApi anyway Fixes #330
…cement for error-prone offer, poll and receiveOrNull Fixes #974
* Fix wrong docs on Job.join and Job.cancelAndJoin Fixes #2615
* Deprecation and migration of receiveOrNull and onReceiveOrNull. * Raise deprecation level for members, introduce deprecation for extensions * Explain rationale behind deprecation * Provide default implementation for deprecated members in Channel interface * Get rid of the internal implementation, leverage receiveCatching * Introduce new extensions for ChannelResult and use them as a replacement in our own operators Fixes #1676
The implementation of Reactive Streams' Subscriber used for `await*` operations was assuming that the publisher is correct. Now, the implementation detects some instances of problematic behavior for publishers and reports them. Fixes #2079
…entical 'ensureActive' extension to reduce code duplication (#2467)
* Remove all deprecated inline methods * Move the rest to the Deprecated.kt * Apply Deprecated.HIDDEN where possible, otherwise use internal + published API
* Remove all deprecated inline methods * Promote ERROR to HIDDEN where applicable * Promote WARNING to ERROR where applicable
* Embrace new channel API * Introduce trySendBlocking and deprecate sendBlocking * Use it in callbackFlow example * Stabilize callbackFlow and channelFlow as they finally have error-safe API * Irrelevant: migrate from deprecated stdlib API to be able to build with Kotlin 1.5 Co-authored-by: Roman Elizarov <[email protected]>
* Otherwise Kotlin users with non-reactive background get confused by flow/stdlib inconsistency * Make it experimental to delay the final decision about the name Fixes #2641
…ages along the codebase (#2644) * Deprecate SendChannel.offer and replace its usages along the codebase * Deprecate ReceiveChannel.poll and replace its usages along the codebase Co-authored-by: Roman Elizarov <[email protected]> Addresses #974
#2647) * Mark BroadcastChannel, ConflatedBroadcastChannel and all related operators as obsolete API replaced with SharedFlow and StateFlow * Remove operator fusion with deprecated broadcastIn in order to simplify further Flow maintenance
* Migrate inline classes to value classes * Adjust debugger/state recovery for new codegen * Temporarily disable R8 tests * Update webpack for new K/JS
* Fixed `PublisherCoroutine`, `rxObservable`, and `Flow.toPublisher` ignoring cancellations. * Fatal exceptions are not treated in a special manner by us anymore. Instead, we follow the requirement in the reactive streams specification that, in case some method of `Subscriber` throws, that subscriber MUST be considered canceled, and the exception MUST be reported in someplace other than `onError`. * Fixed `trySend` sometimes throwing in `PublisherCoroutine` and `rxObservable`. * When an exception happens inside a cancellation handler, we now consistently throw the original exception passed to the handler, with the new exception added as suppressed. * Fixed `PublisherCoroutine` and `rxObservable` claiming that the channel is not closed for send for some time after `close()` has finished. * Fixed publishers sometimes signalling `onComplete()` after cancellation even though their streams are not finite. Fixes #2173
…hout it (#2637) Also, remove the tutorial variant of the basic coroutine introduction as it essentially duplicates the content of the basic coroutine introduction, albeit with "how to create a project" additional information, which does not seem to be appropriate in this section at all. Fixes #2122 Co-authored-by: Vsevolod Tolstopyatov <[email protected]> Co-authored-by: Andrey Polyakov <[email protected]>
…deadlocks when the downstream throws, but other flow has no elements in it (#2659) Fixes KT-46013
* Clarify docs about the restriction on MutableSharedFlow function's onBufferOverflow parameter. * Clarify docs about MutableSharedFlow function without subscribers but with onBufferOverflow Co-authored-by: Zach Klippenstein <[email protected]>
…nd Maybe (#2628) * Deprecated `awaitSingleOr*` on arbitrary Publishers * Added specialized `awaitSingle` and `awaitSingleOrNull` methods on `Maybe<T>` and `Mono<T>` * Deprecated `Maybe<T>.await()` in favor of `Maybe<T>.awaitSingleOrNull()` * Added specializations of most of the `await*` methods for `Mono<T>` and deprecated them, as the only useful methods on `Mono<T>` are `awaitSingle` and `awaitSingleOrNull` * Reworded some documentation for `await*` methods Fixes #2591 Fixes #1587
…routines-core (#2632) * It fixes IDEA issue that was introduced in coroutines 1.4.3 where we switched to Kotlin 1.4.30 and stopped producing root artifact with JVM classes * It simplifies manual -javaagent specification for end-users who shouldn't even be aware of kotlinx-coroutines-core-jvm.jar Fixes #2619
* Establish clear contract on ChannelResult.isClosed * This method provides a **clear** migration from correct 'offer' usages to 'trySend'
…#2638) * On JVM it uses java.util.concurrent.CancellationException, same as stdlib declaration * Fully backwards compatible for JVM, Native-friendly for Obj-C interop
* Remove dev repositories and Bintray usages where applicable * Update our frontend example * Update lincheck * Temporary ignore MutexLincheckTest.modelCheckingTest
Reworked the comments, added new tests. Fixed a bug where `Maybe.collect()` would hang on success.
# Conflicts: # README.md # gradle.properties
* Update Kotlin to 1.5.0 * Update atomicfu to 0.16.1 Co-authored-by: SokolovaMaria <[email protected]>
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.