Stream: Pipe, back pressure about futures-rs HOT 2 CLOSED

Back pressure handling is built into the entire stream system (and future system) in a much more robust way than node has done IMO. Your future / stream construction represents the flow of data from the leaves (where data enters the future/stream system) down to the root future... the one you use to trigger the computation.

Since future-rs works via poll instead of push (and this is what is unique about futures-rs), none of the combinators will buffer up data. Instead, they will only operate when the entire system has capacity to handle more data. This means that buffering logic is delegated to the leaf futures aka the ones that push data into the system from the outside world (I should note that you can also add explicit buffering points by using a buffer combinator).

The reason why futures::stream::channel has the note that you pointed out is because it is a "leaf node" in your future computation. Aka, you use it to push data in.

Another point of comparison vs. node's streams. Since future-rs is entirely poll based, there is no need for a function to "pause" the stream. You simply don't poll. This is important because "pausing" a concurrent computation is inherently racy. A poll strategy has clearer guarantees.

from futures-rs.

Indeed! I think @carllerche covered it pretty well, in that the theory is "backpressure" is everywhere by default.

We may eventually want to add some sort of Sender::pipe method on the sending half of a channel which pipes one stream into a channel, but that should also handle backpressure by default due to the polling effects.

As I think this is basically all taken care of, closing, but thanks for the report!

from futures-rs.