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

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?

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

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)?

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"));

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

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

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

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?

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

1 Like

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.