Soft question: future, stream, and Vec<future>

[zeroexcuses]

Consider the following problem, say we make 10,000 concurrent GET requests.

We now have requests: Vec<Future<...>>.

These requests may be returned in arbitrary order. We can not assume req1 returns, then req2 returns, then req3 returns etc ...

In this case, does it make sense to use the Stream in futures::stream - Rust api ?

if yes:

that page states:

If Future<Output = T> is an asynchronous version of T , then Stream<Item = T> is an asynchronous version of Iterator<Item = T> . A stream represents a sequence of value-producing events that occur asynchronously to the caller.

but that does not seem to make sense in our case, since the 10,000 GET requests can return in any order

if no:

what futures related API should I be looking at instead ?

[moy2010]

The difference between a Vec and a Stream is that a Vec has already allocated memory for the 10K requests, while a Stream will process them in chunks (it doesn't allocate space for the 10K requests in advance).

If you already have the connections, I guess you are thinking about FuturesUnordered: FuturesUnordered in futures::stream - Rust.

[zeroexcuses]

@moy2010

If you already have the connections, I guess you are thinking about FuturesUnordered: FuturesUnordered in futures::stream - Rust .

Yeah, I already have the connections. Sorry for not making this clear. FuturesUnordered looks very interesting.

[alice]

I would probably have designed this in the following way:

1. Spawn each request using tokio::spawn.
2. Control number of concurrent requests using a Semaphore.
3. Receive responses using a tokio::sync::mpsc channel.