question about j.u.c.Flow.Subscription

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

question about j.u.c.Flow.Subscription

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

Re: question about j.u.c.Flow.Subscription

Dávid Karnok
Hello,

the original reactive-streams spec calls for limited recursion between onNext() and request() which is what is the expectation in j.u.c.Flow as I see.

There are several "schools" of implementing reentrant-safe and thread-safe Subscriptions. I personally like to use atomic increments and separate state flags whereas j.u.c. seems to use compact state values with CAS loops.

In fact, I can point you to a full-featuted fluent implementation of the reactive-streams API that had to deal with this exact situation in many forms and shapes.

2015-09-14 18:03 GMT+02:00 Michael McMahon <[hidden email]>:
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Best regards,
David Karnok

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

Re: question about j.u.c.Flow.Subscription

Viktor Klang
In reply to this post by Michael McMahon
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]."

[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?



On Mon, Sep 14, 2015 at 6:03 PM, Michael McMahon <[hidden email]> 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
[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: question about j.u.c.Flow.Subscription

Michael McMahon
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]."

[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?



On Mon, Sep 14, 2015 at 6:03 PM, Michael McMahon <[hidden email]> 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
[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: question about j.u.c.Flow.Subscription

Viktor Klang
Michael,

nested invocations does not count as concurrent (see discussion somewhere around here),
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 <[hidden email]> 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]."

[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?



On Mon, Sep 14, 2015 at 6:03 PM, Michael McMahon <[hidden email][hidden email]> 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
[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: question about j.u.c.Flow.Subscription

Viktor Klang
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 <[hidden email]> wrote:
Michael,

nested invocations does not count as concurrent (see discussion somewhere around here),
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 <[hidden email]> 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]."

[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?



On Mon, Sep 14, 2015 at 6:03 PM, Michael McMahon <[hidden email][hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



--
Cheers,




--
Cheers,



--
Cheers,

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest