2

A call to poll can never block, otherwise the entire thread the async core executes on will be blocked, stopping all possible causality until the blocking function returns.

I spawn a future onto the reactor, and there are a series of combinators like my_future.and_then(…).map(…).then(…).

The reactor polls the future, and then before it executes the next and_then combinator, does the reactor iterate through all other futures, checking to see if they are ready, or does the reactor follow through with all the combinatorial steps of my_future.and_then(…).map(…).then(…)?

I am asking this question because it is important to know how to design my program given the causality of the async core.

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
Thomas Braun
  • 505
  • 3
  • 14

1 Answers1

2

As far as the asynchronous executor knows, there aren't intermediate steps. Each combinator consumes the previous future, producing a brand new future. At the end, a single future is handed to the executor and it calls poll on that future as required.

It is up to each parent future to decide if and when any child futures are polled, but this can only happen when the parent future is polled.

See also:

Shepmaster
  • 388,571
  • 95
  • 1,107
  • 1,366
  • Ah, so the power of setting up causal-chains is up to the coder, and not necessarily the Reactor then? – Thomas Braun Jun 25 '19 at 15:56
  • 1
    @ThomasBraun if I understand your terminology, then yes. I have a hard time imagining it any other way, to be honest. How would the executor know that future A needs to have child future B called but not child C, etc? Remember that the docs link to the corresponding source code, so you can see how e.g. [`Select`](https://docs.rs/futures/0.1.27/futures/future/struct.Select.html) is [implemented](https://docs.rs/futures/0.1.27/src/futures/future/select.rs.html#45-70). – Shepmaster Jun 25 '19 at 16:00