[concurrency-interest] Clarifications request for Reactive Streams Specification Rule 1.1

Pavel Rappo pavel.rappo at gmail.com
Thu Nov 2 14:37:41 EDT 2017


Viktor,

Sorry for the misleading title. However, I would appreciate if someone clarifies
this passage. The intent section claims the rule has an implication. In my
opinion an implication is a (even though implicit) first class citizen in the
spec. Because if I cannot verify an implication from a rule, I cannot verify the
rule itself.

An intent section is more about "why it is so" (commentary if you wish).

On Thu, Nov 2, 2017 at 8:58 PM, Viktor Klang <viktor.klang at gmail.com> wrote:
> Pavel,
>
> On Thu, Nov 2, 2017 at 5:49 PM, Pavel Rappo via Concurrency-interest
> <concurrency-interest at cs.oswego.edu> wrote:
>>
>> I think this question is both about concurrency in Java and Reactive
>> Streams.
>> Thus posting it to a place where it could be seen by all interested
>> parties.
>>
>> >    Rule #1.1
>> >
>> >    The total number of onNext's signalled by a Publisher to a Subscriber
>> > MUST
>> >    be less than or equal to the total number of elements requested by
>> > that
>> >    Subscriber's Subscription at all times.
>> >
>> >    The intent of this rule is to make it clear that Publishers cannot
>> > signal
>> >    more elements than Subscribers have requested. There’s an implicit,
>> > but
>> >    important, consequence to this rule: Since demand can only be
>> > fulfilled
>> >    after it has been received, there’s a happens-before relationship
>> > between
>> >    requesting elements and receiving elements.
>>
>> It sounds like it is more about causality than happens-before.
>>
>> Like if there is
>> an Subscriber.onNext call in the execution, it must be that there was at
>> least a
>> single Subscription.request call in that execution earlier.
>>
>>
>> If it is really about happens-before, the rule might benefit from the
>> following
>> clarification ("concurrent collections" style):
>>
>>     Actions in a thread prior to requesting an item from a Subscription
>>     happen-before actions subsequent to receiving of that item in
>>     Subscriber.onNext in another thread.
>>
>> However, since we don't know an element before we receive one in onNext,
>> it can
>> be quite tricky to formulate that clearly.
>
>
> The Intent-section of the rule is not the specification of the rule. :)
>
>>
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> --
> Cheers,
>


More information about the Concurrency-interest mailing list