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

Viktor Klang viktor.klang at gmail.com
Mon Sep 14 15:56:57 EDT 2015


And thanks to our conversation I now also remembered that I ought to
clarify that in the spec, so thank you!

On Mon, Sep 14, 2015 at 9:53 PM, Viktor Klang <viktor.klang at gmail.com>
wrote:

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



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


More information about the Concurrency-interest mailing list