Skip to content

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

Closed
benjchristensen opened this issue Feb 28, 2015 · 4 comments
Closed

2.0 Design: Disposal and Cancellation #2782

benjchristensen opened this issue Feb 28, 2015 · 4 comments
Milestone

Comments

@benjchristensen
Copy link
Member

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:

  • RS == Reactive Streams
  • in RxJava v1 the Producer is equivalent to RS Subscription
  • there is no equivalent in RS for the RxJava v1 Subscription
  • in Rx.Net/RxJS a Disposable is equivalent to RxJava v1 Subscription

In RxJava v2:

  • a Subscription is the RxJava v1 Producer that manages the request(n) and cancel semantics
  • non-subscription related source cleanup may be provided by a Disposable

We need to figure out how to unify or clearly communicate cancel and dispose semantics since they are different.

For example, the RS Subscription can not be used to represent a scheduled task in a Scheduler, since request(n) does not make sense there. A Disposable that can be disposed could represent it. A Disposable could be disposed when a Subscription is canceled.

@benjchristensen benjchristensen added this to the 2.0 milestone Feb 28, 2015
This was referenced Feb 28, 2015
@akarnokd
Copy link
Member

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 Cancellable and cancel() but I guess Disposable is the name to work with; and cancel() might not be a good word expressing the handling of resources.

@benjchristensen
Copy link
Member Author

In the 2.x branch right now there are subscribe overloads that return Disposable. If this is permitted, then it seems to mean we have volatile requirements, which we have discussed avoiding (#2784 (comment)).

How is the concurrency of cancel inside LambdaSubscriber dealt with? Does the issue of volatile checks not exist due to the Reactive Stream API?

@akarnokd
Copy link
Member

How is the concurrency of cancel inside LambdaSubscriber dealt with

With terminal-atomics, the same logic that happens in the resource containers. If not cancelled, the onSubscribe takes only ~30 cycles longer (~10ns).

@akarnokd
Copy link
Member

Closing as resolved.

We have org.reactivestreams.Subscription for the channel between Publisher and a Subscriber implementations. All the other base reactive types and schedulers use Disposable.

The internal SubscriptionHelper and DisposableHelper support various state management and atomic operations with these types.

Sometimes operators need both or implement both Subscription and Disposable where either cancel delegates to dispose or vice versa.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants