Summary:
When the `send_async` method is used to dispatch multiple concurrent requests, the method needs to return an `AsyncResponse` for each request. Since `AsyncResponse`'s constructor is itself `async` (it waits for all of the headers to be received), internally the method ends up with a collection of `AsyncResponse` futures.
Previously, in an attempt to simplify the API, the method would insert all of these futures into a `FuturesUnordered`, thereby conceptually returning a `Stream` of `AsyncResponses`. Unfortunately, this API ends up making it harder to consume the resulting `AsyncResponses` concurrently, as one might want to do when streaming lots of data over several concurrent requests.
This diff changes the API to just insert the `AsyncResponse` futures into a `Vec` to allow the caller to use them as desired. To maintain compatibility with the old behavior for the sake of this diff, the one current callsite has been updated to just dump the returned `Vec` into a `FuturesUnordered`. This will be changed later in the stack.
Reviewed By: quark-zju
Differential Revision: D29204195
fbshipit-source-id: ecee8cff430badd8213c2efef62fc68fbd91fde9
Any native code (C/C++/Rust) that Mercurial (either core or extensions)
depends on should go here. Python code, or native code that depends on
Python code (e.g. #include <Python.h> or use cpython) is disallowed.
As we start to convert more of Mercurial into Rust, and write new paths
entrirely in native code, we'll want to limit our dependency on Python, which is
why this barrier exists.
See also hgext/extlib/README.md, mercurial/cext/README.mb.
How do I choose between lib and extlib (and cext)?
If your code is native and doesn't depend on Python (awesome!), it goes here.
Otherwise, put it in hgext/extlib (if it's only used by extensions) or
mercurial/cext (if it's used by extensions or core).
ca8200e9df