2.0 Design: Disposal and Cancellation

[benjchristensen]

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.

[akarnokd]

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]

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]

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]

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.