3.5 Why is thread-safety of Subscription.cancel() required?

[anthonyvdotbe]

Rule 3.5 says that Subscription.cancel() MUST be thread-safe.
Why is this so, given that rule 2.7 excludes the possibility of Subscription.cancel() being invoked concurrently? Why isn't it sufficient if the fact of cancellation is guaranteed to be visible to any subsequent calls on the Subscription?

For example, say I have something like the following:

volatile boolean cancelled = false;

public void cancel() {
    myHashMap.put("hello", "world");
    cancelled = true;
}

Why isn't this allowed?

[akarnokd]

Experience with RxJava 2, Rsc and Reactor indicates that rule 2.7 adds unnecessary burden because cancels can happen from any thread and in any numbers. For example, a timeout cancels a stream that is cancelled by a limiting operator at the same time.

In contrast, making cancel thread safe is usually very simple, just like in your example. It usually sets a cancelled flag, or performs some CAS that succeeds only once and does cleanup, etc.

[viktorklang]

@akarnokd Why would it be a burden, all which is required is to wrap the original Subscription in a safe wrapper? Or did I misunderstand?

[akarnokd]

It's not only the wrapping but the serialization primitive overhead. Plus the hundreds of operators I've written, the thread-safe cancellation was an easy / trivial thing (see linked by the examples).

[viktorklang]

@akarnokd Yes, threadsafe cancellation is "easy", however, should the spec mandate how it is implemented? Or what do you propose given your experience?

[akarnokd]

Drop §2.7. §3.5 is fine by itself.

[viktorklang]

@akarnokd §2.7 covers more than cancel though.

[viktorklang]

AFAIR addressed by #339