Skip to content
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

Equivalent of tokio::task::JoinSet #308

Open
joshtriplett opened this issue Jun 2, 2024 · 4 comments
Open

Equivalent of tokio::task::JoinSet #308

joshtriplett opened this issue Jun 2, 2024 · 4 comments

Comments

@joshtriplett
Copy link
Contributor

I'd love to have an equivalent of tokio::task::JoinSet: a type that provides a spawn method, saves the join handle, and provides an operation to wait for the next task in the set to complete.

In addition to the methods provided by JoinSet, it'd also be nice to have an asynchronous spawn method that takes a concurrency limit, and if there are more than that number of items in the set, waits for the next task to complete before spawning another item.

@notgull
Copy link
Member

notgull commented Jun 8, 2024

Is there something JoinSet can do that's non-trivial to do with a Vec<Task<()>>? Personally I've never felt the need for it, but if there's a good reason, then we can model it out and consider adding it.

In addition to the methods provided by JoinSet, it'd also be nice to have an asynchronous spawn method that takes a concurrency limit,

This can be done now with a Semaphore, see this example.

@joshtriplett
Copy link
Contributor Author

@notgull A JoinSet isn't ordered; when you wait on the next completion from it, it returns the next completion regardless of its position.

@notgull
Copy link
Member

notgull commented Jun 8, 2024

@yoshuawuyts This is basically futures-concurrency::FuturesGroup, right?

@yoshuawuyts
Copy link
Member

Yes that's right! - Rather than calling spawn though, you call push. And it returns an async iterator of values (Stream trait right now for compat reasons).

Conceptually it's very similar to FuturesUnordered, with the one main difference being that it supports lending iteration - so you can add more futures to the group while iterating over it, without needing to resort to something like select! 1.

Footnotes

  1. The main only caveat I'd add is that I messed up the internal slab implementation, and I really should merge https://github.com/yoshuawuyts/futures-concurrency/pull/187 in the meantime to fix some of that. But beyond that: yes, I think this sounds like it should largely be a match.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants