Clarifications request for Reactive Streams Specification Rule 1.1

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Clarifications request for Reactive Streams Specification Rule 1.1

JSR166 Concurrency mailing list
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.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications request for Reactive Streams Specification Rule 1.1

JSR166 Concurrency mailing list
Pavel,

On Thu, Nov 2, 2017 at 5:49 PM, Pavel Rappo via Concurrency-interest <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications request for Reactive Streams Specification Rule 1.1

JSR166 Concurrency mailing list
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 <[hidden email]> wrote:

> Pavel,
>
> On Thu, Nov 2, 2017 at 5:49 PM, Pavel Rappo via Concurrency-interest
> <[hidden email]> 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
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> --
> Cheers,
> √
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications request for Reactive Streams Specification Rule 1.1

JSR166 Concurrency mailing list
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 elaborates on the requirements, but most specifically in this case is, I believe, 3.8.

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

On Thu, Nov 2, 2017 at 7:37 PM, Pavel Rappo <[hidden email]> 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 <[hidden email]> wrote:
> Pavel,
>
> On Thu, Nov 2, 2017 at 5:49 PM, Pavel Rappo via Concurrency-interest
> <[hidden email]> 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
>> [hidden email]
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>
>
> --
> Cheers,
> √



--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Clarifications request for Reactive Streams Specification Rule 1.1

JSR166 Concurrency mailing list
On Fri, Nov 3, 2017 at 12:20 AM, Viktor Klang <[hidden email]> wrote:
> Speaking of verification, has the TCK helped you with the interpretations?

Sort of. I've run tests, but haven't yet dug into their implementation.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest