3.1 refinement/explanation

[anthonyvdotbe]

§3.1 says:

Subscription.request and Subscription.cancel MUST only be called inside of its Subscriber context. A Subscription represents the unique relationship between a Subscriber and a Publisher [see 2.12].

To me, it's unclear what inside of its Subscriber context means here (note that this has been brought up before by @akarnokd in #228). This was explained in #177 by @akarnokd as:

Not sure what it meant. In practice, exposing a Subscription outside its target Subscriber can lead to race condition with the Subscriber's own logic. First, the Subscription itself may arrive late and thus you can't cancel it or request values from it upfront. Second, issuing extra request could overflow the Subscriber's logic or cancelling the upstream may leave the Subscriber hang and leaking resources.

and by @viktorklang as:

See §2.7 for more background. Linking to §2.7 from §3.1 seems like a good idea.

The word context is particularly troublesome because it's so vague. Upon first reading this rule, I thought of things like class loaders (Thread::getContextClassLoader) and security (java.security.AccessControlContext). Or maybe some lexical constraint, where the Subscriber context is defined as all code lexically enclosed by the Subscriber's class definition.

Actually, the most logical explanation I can think of, is that it's intended to prohibit Publishers from calling methods on the Subscription. But if so, why not simply add a Publisher rule saying:

A Publisher MUST NOT call any methods on the Subscription.

If the Publisher is prohibited from calling methods on the Subscription, and the Subscriber obeys rule 2.7, what would the added value of rule 3.1 still be?

On another note, I feel the second sentence:

A Subscription represents the unique relationship between a Subscriber and a Publisher [see 2.12].

does not belong in the rule, since it doesn't actually specify anything. Maybe it could be moved outside of the table, as an explicative line right after the title?

[viktorklang]

Apologies for the delay here, fixed in #339