Are you referring to `Subscription.cancel` and `Subscription.request`? What 'same thread`? The thread that the `Subscriber` uses for async dispatch? The thread the `Publisher` is sending me data on?

I think this is the wrong place for this rule and I actually find it ambiguous. 

Beyond that, a `Subscription` should be capable of handling these calls from anywhere so that a `Subscriber` doesn't have to worry about it. The burden is on the `Publisher`, a `Subscriber` should be able to call `request(n)` from anywhere.

This is similar to the reason why these exist in the current README for `Subscription`:

- Calls from a Subscriber to Subscription.request(int n) can be made directly since it is the responsibility of Subscription to handle async dispatching.
- The Subscription.request method MUST assume that it will be invoked synchronously and MUST NOT allow unbounded recursion such as Subscriber.onNext -> Subscription.request -> Subscriber.onNext.

Not that these are for protecting against stack overflow, but equally important is that it does not require it to be synchronous, and it's often going to be that `request` will be calling asynchronously, and concurrent to the `Publisher` producing data, thus the `Subscription` must by definition be thread-safe and handling concurrent invocation of `request` and `cancel`.