JDK 9 Flow javadoc example SampleSubscriber requesting

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

JDK 9 Flow javadoc example SampleSubscriber requesting

Dávid Karnok
Given a synchronous end-consumer Flow.Subscriber of a Flow.Publisher, generally there is no reason to request in parts/batches and almost all should be able to request Long.MAX_VALUE at the beginning. The reason for it is that such consumers have a natural call-stack blocking and until the onNext returns, they won't receive another onNext.

One of the few reasons one would use such batching if the onNext implementation goes async to execute the consumer.accept:

public void onNext(T item) {
  singleThreadedExecutor.execute(() -> {
    if (--count <= 0)
      subscription.request(count = bufferSize - bufferSize / 2);
      consumer.accept(item);
    }
  });
}

Batching has more sense in operators built with the help of Subscribers (like flatMap and observeOn) but those are too complicated in on themselves to be shown as examples.

I can understand the example is to show off the features/patterns one can utilize but it might be worth mentioning the effects of synchronous consumption with respect to requesting. 

Another reason to clarify is that people have consumers implemented as such in RxJava and wondered why the top source didn't respect their request amount: it generated 128 elements upfront even though they requested 1 over a chain of various async stages (and in fact received only one but there was another 127 ready to be emitted). 

RS requesting is a property between two subsequent stages and each stage can decide - while respecting the spec - how much to prefetch and how to translate downstream request into an upstream request.




--
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: JDK 9 Flow javadoc example SampleSubscriber requesting

Doug Lea
On 09/24/2016 10:08 AM, Dávid Karnok wrote:
> Given a synchronous end-consumer Flow.Subscriber of a Flow.Publisher, generally
> there is no reason to request in parts/batches and almost all should be able to
> request Long.MAX_VALUE at the beginning.

The UnboundedSubscriber code example shows this usage, prefaced with

"...when flow control is never needed, a subscriber may initially request an
effectively unbounded number of items..."

Suggestions for improving that sentence would be welcome. But
I'm not sure we can/should say anything in top-level specs
about the situations in which "flow control is never needed".
Even some synchronous cases might use buffering.

-Doug


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

Re: JDK 9 Flow javadoc example SampleSubscriber requesting

Dávid Karnok
Hi Doug and thanks for the reply.

I wish I could offer a better sentence but I'm always struggling with explaining such things in our javadocs as well. All I can suggest is to have the unbounded example before the bounded example so people really needing bounded tips can continue reading while most people can stop at the unbounded example.

2016-09-24 18:23 GMT+02:00 Doug Lea <[hidden email]>:
On 09/24/2016 10:08 AM, Dávid Karnok wrote:
Given a synchronous end-consumer Flow.Subscriber of a Flow.Publisher, generally
there is no reason to request in parts/batches and almost all should be able to
request Long.MAX_VALUE at the beginning.

The UnboundedSubscriber code example shows this usage, prefaced with

"...when flow control is never needed, a subscriber may initially request an effectively unbounded number of items..."

Suggestions for improving that sentence would be welcome. But
I'm not sure we can/should say anything in top-level specs
about the situations in which "flow control is never needed".
Even some synchronous cases might use buffering.

-Doug


_______________________________________________
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