-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
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
Make tokio / async-io optional task execution engines #2624
Conversation
I'd love to have this option! The |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a compelling little opt-in feature, and the design is very clean. I like the block_on re-export a lot.
The changes here are very scoped.
bors try |
tryMerge conflict. |
@hanabi1224 Sorry that this has been left in limbo for so long. If you're around, could you rebase this? If we don't hear back by the time this is ready to merge, we'll do so ourselves (and credit you as the author regardless). |
You can run tokio futures on bevy's executor today with https://docs.rs/async-compat/latest/async_compat/. What's the advantage of this approach over that? |
@alice-i-cecile No problem, I just resolved all conflicts and have all CI jobs passing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems like a great change for those looking for tokio support or in general better async task performance.
However, I don't see any initialization code at all or anything that enqueues tasks added to TaskPool
s to the global executors. If the intent is just to allow global executors to run alongside the Bevy TaskPool
s, this change is sufficient, though I'm concerned with how we're adding yet more threads to the engine by default, but if we want to leverage them for running the core of bevy itself, there will need to be changes with how TaskPool
is structured.
@@ -36,4 +36,6 @@ | |||
|wayland|Enable this to use Wayland display server protocol other than X11.| | |||
|subpixel_glyph_atlas|Enable this to cache glyphs using subpixel accuracy. This increases texture memory usage as each position requires a separate sprite in the glyph atlas, but provide more accurate character spacing.| | |||
|bevy_ci_testing|Used for running examples in CI.| | |||
|tokio|Use tokio as task execution engine.| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these two features mutually exclusive? If they are, this docs should cover that mutual exclusion.
Hello, is this feature still being considered? It would be nice to be able to use tokio with bevy |
Yes, it's being considered, but not something that's particularly pressing. @mockersf, how do you feel about this? Would you vote to start the bypass timer? I'm not immediately sure I would, but I want your opinion. |
The PR looks mostly good but it could use some cleanups and conflict resolution before doing that. @hanabi1224 are you still around? Sorry for the long delay, could you update the PR? Otherwise we can mark it as available for adoption |
Closed in favor of #6137. |
Make tokio / async-io optional task execution engines behind optional features
Objective
Solution
on_block
method from bevy_tasks crate under bevy::tasks namespace, so that users don't need to depend on a task engine explicitly.