-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
join! macro to join more than two futures? #6
Comments
This is easy to add, but right now I've stumbled on an open design question. In the So the macro version Speaking from experience, this is sometimes confusing. Reading code, it can be hard to tell whether a macro does or does not contain an I wonder if |
Related: rust-lang/futures-rs#2127 |
I think that it makes sense to have to Still it seems worth making the it functionally similar to the join function I think. |
I agree that it makes sense to not hide the await inside the macro. However, it also seems potentially confusing to have two Perhaps it would help to use a different name for this macro in futures-lite? That gives the opportunity for someone to see documentation. |
What if we called this
Look, it makes sense:
|
@stjepang Sold. That makes perfect sense to me. That would allow |
👍 for me. I think that makes a lot of sense. |
Why not add a |
|
I just wanted to simply wait for several futures in parallel, without even required for the results to be returned. Then I looked at the implementation of |
The use async_executor::LocalExecutor;
let exec = LocalExecutor::new();
let mut handles = vec![];
for future in futures_to_run() {
handles.push(exec.spawn(future));
}
exec.run(async move {
for handle in handles {
handle.await;
}
}); |
not sure who this may help but I was able to get really far with just use std::future::Future;
use async_executor::{LocalExecutor, Task};
pub async fn join_all<F, T, E>(futures: Vec<F>) -> Result<Vec<T>, E>
where
F: Future<Output = Result<T, E>>,
{
let exec = LocalExecutor::new();
// Spawn each future onto the executor and collect the task handles
let handles: Vec<Task<Result<T, E>>> = futures.into_iter()
.map(|future| exec.spawn(future))
.collect();
// Run the executor and join all the tasks
exec.run(async move {
let mut results = Vec::with_capacity(handles.len());
for handle in handles {
results.push(handle.await?);
}
Ok(results)
}).await
} let mut futures = vec![];
for chunk in &chunks {
futures.push(Robinhood::get_marketdata_options(chunk));
}
let results = utilities::join_all(futures).await?; |
…sfers The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, smol-rs/futures-lite#6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based.
…sfers The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, smol-rs/futures-lite#6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based.
…sfers The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, smol-rs/futures-lite#6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based.
…sfers The router will now match the top-level transfer so it isn't used as the justification for the InInstruction it's handling. This allows the theoretical case where a top-level transfer occurs (to any entity) and an internal call performs a transfer to Serai. Also uses a JoinSet for fetching transactions' top-level transfers in the ERC20 crate. This does add a dependency on tokio yet improves performance, and it's scoped under serai-processor (which is always presumed to be tokio-based). While we could instead import futures for join_all, smol-rs/futures-lite#6 summarizes why that wouldn't be a good idea. While we could prefer async-executor over tokio's JoinSet, JoinSet doesn't share the same issues as FuturesUnordered. That means our question is solely if we want the async-executor executor or the tokio executor, when we've already established the Serai processor is always presumed to be tokio-based.
futures-lite implements the
join
function to join two futures. I'd love to have thejoin!
macro to join more than two futures, if that'd be a reasonable addition to futures-lite.The text was updated successfully, but these errors were encountered: