Consider the following problem, say we make 10,000 concurrent GET requests.
We now have
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 ?
that page states:
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
what futures related API should I be looking at instead ?
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.
Yeah, I already have the connections. Sorry for not making this clear. FuturesUnordered looks very interesting.
I would probably have designed this in the following way:
- Spawn each request using
- Control number of concurrent requests using a
- Receive responses using a
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.