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

Viktor Klang viktor.klang at gmail.com
Thu Nov 2 17:20:22 EDT 2017


Pavel,

Yes, there's a causal relationship between the Subscriber demanding more
elements, and those items being delivered,
and that signalling is done in a thread safe manner, so by extension,
request-ing happens-before onNext signalling.
The rules governing Subscription
<https://github.com/reactive-streams/reactive-streams-jvm#3-subscription-code>
elaborates on the requirements, but most specifically in this case is, I
believe, 3.8 <https://github.com/reactive-streams/reactive-streams-jvm#3.8>.

Speaking of verification, has the TCK helped you with the interpretations?

On Thu, Nov 2, 2017 at 7:37 PM, Pavel Rappo <pavel.rappo at gmail.com> wrote:

> 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,
> > √
>



-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171102/a3d85ecc/attachment-0001.html>


More information about the Concurrency-interest mailing list