j.u.c. Flow usecase

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

j.u.c. Flow usecase

JSR166 Concurrency mailing list
Hi,

This is the explanation from Doug Lea I am trying to understand. Push-style and pull-style API's are both mentioned here. Which one is Flow adding support for ? 
NIO, AIO, reactivity and back pressure etc. are somewhat confounding. I think.

Thanks,
Mohan
--------------------
Over the past year, the "reactive-streams"
(http://www.reactive-streams.org/) effort has been defining a minimal
set of interfaces expressing commonalities and allowing
interoperablility across frameworks (including Rx and Akka Play), that
is nearing release. 
"These interfaces include provisions for a simple
form of async flow control allowing developers to address resource
control issues that can otherwise cause problems in push-based
systems. Supporting this mini-framework helps avoid unpleasant
surprises possible when trying to use pull-style APIs for "hot"
reactive sources (but conversely is not as good a choice as
java.util.Stream for "cold" sources like collections)."
--------------------  

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

Re: j.u.c. Flow usecase

JSR166 Concurrency mailing list
Hi Mohan,

Reactive Streams (Flow) can be thought of as ”dynamic push-pull”—its behavior will oscillate at runtime between push (when consumer is faster) and pull (when producer is faster) without intervention. The technical reason for this is that it uses a decoupled amortized pull strategy. Decoupled in the sense that the consumer is free to request more data when it needs it and does not need to wait for data to be received first, amortized in the sense that it can request multiple elements with a single pull, and pull because it is the consumer who is requesting more data.

Cheers,
V

On Tue, 8 Jan 2019 at 09:15, Mohan Radhakrishnan via Concurrency-interest <[hidden email]> wrote:
Hi,

This is the explanation from Doug Lea I am trying to understand. Push-style and pull-style API's are both mentioned here. Which one is Flow adding support for ? 
NIO, AIO, reactivity and back pressure etc. are somewhat confounding. I think.

Thanks,
Mohan
--------------------
Over the past year, the "reactive-streams"
(http://www.reactive-streams.org/) effort has been defining a minimal
set of interfaces expressing commonalities and allowing
interoperablility across frameworks (including Rx and Akka Play), that
is nearing release. 
"These interfaces include provisions for a simple
form of async flow control allowing developers to address resource
control issues that can otherwise cause problems in push-based
systems. Supporting this mini-framework helps avoid unpleasant
surprises possible when trying to use pull-style APIs for "hot"
reactive sources (but conversely is not as good a choice as
java.util.Stream for "cold" sources like collections)."
--------------------  
_______________________________________________
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: j.u.c. Flow usecase

JSR166 Concurrency mailing list

Thanks Victor.

I think these interfaces are provided based on the spec. for library developers to implement ?

Different libraries could implement "dynamic push-pull" in different ways ?

Mohan
On Tuesday, January 8, 2019, Viktor Klang <[hidden email]> wrote:
Hi Mohan,

Reactive Streams (Flow) can be thought of as ”dynamic push-pull”—its behavior will oscillate at runtime between push (when consumer is faster) and pull (when producer is faster) without intervention. The technical reason for this is that it uses a decoupled amortized pull strategy. Decoupled in the sense that the consumer is free to request more data when it needs it and does not need to wait for data to be received first, amortized in the sense that it can request multiple elements with a single pull, and pull because it is the consumer who is requesting more data.

Cheers,
V

On Tue, 8 Jan 2019 at 09:15, Mohan Radhakrishnan via Concurrency-interest <[hidden email]> wrote:
Hi,

This is the explanation from Doug Lea I am trying to understand. Push-style and pull-style API's are both mentioned here. Which one is Flow adding support for ? 
NIO, AIO, reactivity and back pressure etc. are somewhat confounding. I think.

Thanks,
Mohan
--------------------
Over the past year, the "reactive-streams"
(http://www.reactive-streams.org/) effort has been defining a minimal
set of interfaces expressing commonalities and allowing
interoperablility across frameworks (including Rx and Akka Play), that
is nearing release. 
"These interfaces include provisions for a simple
form of async flow control allowing developers to address resource
control issues that can otherwise cause problems in push-based
systems. Supporting this mini-framework helps avoid unpleasant
surprises possible when trying to use pull-style APIs for "hot"
reactive sources (but conversely is not as good a choice as
java.util.Stream for "cold" sources like collections)."
--------------------  
_______________________________________________
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: j.u.c. Flow usecase

JSR166 Concurrency mailing list
Hi Mohan,

you can find all related information here: http://www.reactive-streams.org/

In short, there's a spec, jars, a TCK, and converters to/from org.reactive-streams and java.util.concurrent.Flow

On Wed, Jan 9, 2019 at 8:26 AM Mohan Radhakrishnan via Concurrency-interest <[hidden email]> wrote:

Thanks Victor.

I think these interfaces are provided based on the spec. for library developers to implement ?

Different libraries could implement "dynamic push-pull" in different ways ?

Mohan
On Tuesday, January 8, 2019, Viktor Klang <[hidden email]> wrote:
Hi Mohan,

Reactive Streams (Flow) can be thought of as ”dynamic push-pull”—its behavior will oscillate at runtime between push (when consumer is faster) and pull (when producer is faster) without intervention. The technical reason for this is that it uses a decoupled amortized pull strategy. Decoupled in the sense that the consumer is free to request more data when it needs it and does not need to wait for data to be received first, amortized in the sense that it can request multiple elements with a single pull, and pull because it is the consumer who is requesting more data.

Cheers,
V

On Tue, 8 Jan 2019 at 09:15, Mohan Radhakrishnan via Concurrency-interest <[hidden email]> wrote:
Hi,

This is the explanation from Doug Lea I am trying to understand. Push-style and pull-style API's are both mentioned here. Which one is Flow adding support for ? 
NIO, AIO, reactivity and back pressure etc. are somewhat confounding. I think.

Thanks,
Mohan
--------------------
Over the past year, the "reactive-streams"
(http://www.reactive-streams.org/) effort has been defining a minimal
set of interfaces expressing commonalities and allowing
interoperablility across frameworks (including Rx and Akka Play), that
is nearing release. 
"These interfaces include provisions for a simple
form of async flow control allowing developers to address resource
control issues that can otherwise cause problems in push-based
systems. Supporting this mini-framework helps avoid unpleasant
surprises possible when trying to use pull-style APIs for "hot"
reactive sources (but conversely is not as good a choice as
java.util.Stream for "cold" sources like collections)."
--------------------  
_______________________________________________
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


--
Cheers,

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