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

Viktor Klang viktor.klang at gmail.com
Mon Sep 14 15:53:04 EDT 2015


Michael,

nested invocations does not count as concurrent (see discussion somewhere
around here
<https://github.com/reactive-streams/reactive-streams-jvm/issues/272#issuecomment-110083260>
),
it is recommended to, if demand is to be signalled from within
`onSubscribe` to put the `request` call at the end of that method.

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

> Thanks for the replies. The reactive streams specification seems to cover
> all of these cases in quite a bit more detail than the javadoc.
>
> Eg. rule 1.3 onSubscribe, onNext, onError and onComplete signaled to a
> Subscriber MUST be signaled sequentially (no concurrent notifications).
>
> which suggests that onSubscribe() must return before onNext() can be
> called the first time. Otherwise,
> I might have thought that onNext() could be called from a call to
> Subscription.request() inside
> Subscriber.subscribe().
>
> - Michael.
>
>
> On 14/09/15 18:09, Viktor Klang wrote:
>
> 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>
> 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>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,
>>
>
>


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


More information about the Concurrency-interest mailing list