[concurrency-interest] question about j.u.c.Flow.Subscription

Viktor Klang viktor.klang at gmail.com
Mon Sep 14 13:09:52 EDT 2015


Hi Michael,

It should be covered in the specification under the rule: 2:3

"Subscription.request MUST place an upper bound on possible synchronous
recursion between Publisherand Subscriber[1
<https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#footnote-3-1>
]."

[1] : An example for undesirable synchronous, open recursion would be
Subscriber.onNext -> Subscription.request ->Subscriber.onNext -> …, as it
very quickly would result in blowing the calling Thread´s stack.




The recommended upper bound would be 1, but it is of course up to the
implementation how it wants to do the "trampolining". This rule is also
tested in the TCK.

Does that cover your question?


(link to the 1.0.0 spec:
https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md
)

On Mon, Sep 14, 2015 at 6:03 PM, Michael McMahon <
michael.x.mcmahon at oracle.com> wrote:

> Hi,
>
> I have a question about Flow subscribers and publishers.
>
> Is it allowable for a j.u.c.Flow.Publisher to directly invoke a
> subscriber's methods
> through its subscription object?
>
> For example, can the implementation of Subscription.request(n)
> call Subscriber.onNext() up to n times, before request() returns?
>
> Considering that Subscriber.onNext() will often call Subscription.request()
> you could easily get a recursive loop, but the question is whether
> the spec allows it?
>
> Thanks,
> Michael.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>



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


More information about the Concurrency-interest mailing list