Order of execution of of futures within tokio core.handle.spawn()

help
1

Is the order for future executions defined?

If I have got the sequence of http requests, like the following:

handle.spawn(build_and_send_request_with_body("body for the 1st request"));
handle.spawn(build_and_send_request_with_body("body for the 2nd request"));
handle.spawn(build_and_send_request_with_body("body for the 3rd request"));

will the requests be sent in the order of spawning using a single http connection?

2

I don’t think the order of spawned tasks is defined; as far as the reactor is concerned, they’re independent tasks.

3

Thanks, how can I send a bunch of HTTP data in async way (i.e. the second part being send not waiting for the first part to respond), but in the order: the first part is written to the socket before the second (assuming http2 connection)?

4 
let f = build_and_send_request_with_body("1")
    .and_then(|_| build_and_send_request_with_body("2"))
    .and_then(|_| build_and_send_request_with_body("3"));
handle.spawn(f);
5

Is this using hyper? I’m assuming so. I’m not sure - does it support http2 pipelining/multiplexing?

6

This would wait for the response for req1 before sending req2 and so on.

7

No, this is sequentially, sending the second after the first got a response. Although it is executed by async reactor

8

Good point. I have forgotten that it is not http2 ready, but I heard it is ready if protocol negotiation is not required. Let's say it supports, how can it be expressed using futures?

9

Wouldn't the “network” (say, some transparent proxy) still be allowed to reorder the requests?

1 Like
10

Good point. Do not know. I would expect messages going through one connection are not shuffled, but it seems nginx can shuffle it because it uses multiple http1 connections in the back office.

Ok. Practically I need to rethink my design. Now it becomes a theoretical excercise :slight_smile: I guess it would be easier on the lower layer than hyper or reqwest.