-
Notifications
You must be signed in to change notification settings - Fork 7.6k
2.0 Design: Disposal and Cancellation #2782
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
Comments
I managed to merge the two in CancellableSubscriber. I'm early in porting but so far I managed to get away with this. Resource tracking works the same as in RxJava but under different name. I named my interface |
In the 2.x branch right now there are How is the concurrency of |
With terminal-atomics, the same logic that happens in the resource containers. If not cancelled, the |
Closing as resolved. We have The internal Sometimes operators need both or implement both |
The addition of backpressure to RxJava 1.0 has conflated "subscription cancelation" and "resource cleanup". This was done to retain backwards compatibility.
The design in Reactive Streams and j.u.c.Flow separates the two.
Terminology:
Producer
is equivalent to RSSubscription
Subscription
Disposable
is equivalent to RxJava v1Subscription
In RxJava v2:
Subscription
is the RxJava v1Producer
that manages therequest(n)
andcancel
semanticsDisposable
We need to figure out how to unify or clearly communicate
cancel
anddispose
semantics since they are different.For example, the RS
Subscription
can not be used to represent a scheduled task in aScheduler
, sincerequest(n)
does not make sense there. ADisposable
that can bedisposed
could represent it. ADisposable
could bedisposed
when aSubscription
iscanceled
.The text was updated successfully, but these errors were encountered: