Typos

[pavelrappo]

The intent of this rule is to make sure that Publishers respect a Subscriber’s request to cancel a Subscription when Subscription.cancel() has been called. The reason for eventually is because signals can have propagation delay due to being asynchronous.

"eventually" should be quoted? (otherwise it reads strange)

The intent of this rule is that a Subscriber should not obstruct the progress of the Publisher from an execution point-of-view. In other words, the Subscriber should not starve the Publisher from CPU cycles.

of CPU cycles, not from (wrong preposition?)

The intent of this rule is to highlight that there may be a delay between calling cancel the Publisher seeing that.

...and the Publisher seeing that (missed word?)

The intent of this rule is to complement [see 3.2] by placing an upper limit on the mutual recursion between request and onNext (and eventually onComplete / onError). Implementations are RECOMMENDED to limit this mutual recursion to a depth of 1 (ONE)—for the sake of conserving stack space. An example for undesirable synchronous, open recursion would be Subscriber.onNext -> Subscription.request -> Subscriber.onNext -> …, as it otherwise will result in blowing the calling Thread´s stack.

...as it otherwise will result in blowing the calling thread's stack. (Is there any need for referring to the java.lang.Thread class?)

While not mandated, it can be a good idea to cancel a Processors upstream Subscription when/if its last Subscriber cancels their Subscription, to let the cancellation signal propagate upstream.

...Processor's upstream (apostrophe instead of plural?)

[viktorklang]

"eventually" should be quoted? (otherwise it reads strange)

I think changing it to eventually is perhaps even better, thanks for the suggestion!

of CPU cycles, not from (wrong preposition?)

I thing it was a shortened form of: "starve the Publisher from getting CPU cycles".

...and the Publisher seeing that (missed word?)

Yes! Nice catch.

(Is there any need for referring to the java.lang.Thread class?)

Well, technically it isn't referring to a FQCN, but given that this is reactive-streams-jvm it [Thread] might make the most sense, don't you agree?

...Processor's upstream (apostrophe instead of plural?)

Yes, apostrophe gone missing. :)

Feel free to create a PR with the proposed changes (don't forget to add yourself to the CopyrightWaivers-file, https://github.com/reactive-streams/reactive-streams-jvm/blob/master/CopyrightWaivers.txt), and we can have the discussing there.

[pavelrappo]

@viktorklang

Well, technically it isn't referring to a FQCN, but given that this is reactive-streams-jvm it [Thread] might make the most sense, don't you agree?

It's just about consistency. I've noticed thread-related things are referred to in different styles in this spec. Thread, Thread, thread, thread-safe, thread-safe, etc.

So maybe a question I should ask first is this: what does text formatted as code mean in the context of this spec?

[viktorklang]

@pavelrappo these things in the spec refer to code concepts (methods, classes, types, values). The only excpetions that I find through a cursory look is "thread-safe" which arguably should be in the glossary-section instead, with a link where it is used.

For "thread", I think this ("thread") is the most frequent—and refers to "thread of execution". I think the two(?) cases of "Thread" can be safely changed to "thread".

[viktorklang]

@pavelrappo See #409