macroquad
macroquad copied to clipboard
not-fl3
using tokio async runtime
There are multiple reasons the tokio runtime cannot be used:
- the tokio runtime does not work on wasm
- the tokio runtime uses threads
macroquad is entirely single-threaded and needs to work on wasm.
What could be done instead is to implement https://docs.rs/async_executors/0.4.2/async_executors/iface/trait.LocalSpawnHandle.html or https://docs.rs/agnostik/0.2.3/agnostik/trait.LocalAgnostikExecutor.html (the latter having fewer dependencies) for a macroquad-specific executor ZST, so that libraries that are built generically on top of async_executors or agnostik just work out of the box.
I am building a desktop application and solved it by spawning macroquad into a separate thread:
fn main()
open_window()
It is sad that this is not possible. I need an web server running so I have an tokio runtime anyway. It is annoying that I need to an complete second runtime for this.
For example I am forced to use tokio mutex/channels blocking in a asnyc context(macroquad runtime) now.
Is this is no supported because tokio does not work on WASM or can macroquad not deal with multi-threads?
The issue is that macroquad uses async because Rust does not have stable Generators yet. You can't actually do anything async in macroquad, every await point basically steps to the next frame.
Thanks for clarification. Maybe the doc should point out this more. The current doc sounds like macroquad is using a "normal" single threaded async runtime.
Can this be fixed? I might be missing something but why can't macroquad just use another mechanism to signal the frame advance, and leave async alone?
Macroquad could (and should) be using generators instead of async, but generators aren't stable or convenient yet.
I might be missing something but why do you even need generators for this?
macroquad needs generators because at least for some platforms a function gets called that tells macroquad to update. However, for users of macroquad it is obviously nicer to create something that looks like a loop when creating the update loop.
Either way, generators or something like it are needed on those platforms to carry the program state across the update calls.
I see what you're saying now-- if you're dead set on presenting an API like that, I guess it is the only option right now. But it is pretty confusing and limiting, although I guess power users can always start their own runtime?
The only other API that macroquad would be able to expose would need the user to give macroquad a function pointer (notice the function pointer part, not a full blown closure, so no ability to capture state) and have the user deal with carrying the state across calls themselves. Not very ergonomic or friendly to new people.
It's pretty standard to just have an update/render callback with a parameter for user data. If you don't like that API then I understand that though.
actually, that API would have problems when it comes to loading files on the web.....
technically possible but rather awkward to use
That would be incompatible with Wasm support afaict. You can already spawn a thread yourself and run a tokio runtime in there. It just won't interact with the async used in macroquad.
Why not allow us to run this in one thread of many and support Tokio for network operations?
You can already spawn another thread that contains tokio. (Unless you are on wasm but it sounds like tokio doesn't work on that environment anyway)
Can we at least have an option to turn wsam support off?
I don't see WSAM support as a defining feature of this library. So arbitrarily neutering it to be single threaded doesn't seem like a reasonable design decision.
I'm not the maintainer, so take this with a grain of salt:
Making non-Wasm use tokio will require quite a bit of effort, it may not be worth it, considering you can add tokio support outside this crate.
Is tokio or async in general really desirable? It adds unpredictable elements to the game loop, when all it really wants is a way to tick frames reliably. I certainly see the benefits around loading large things that take longer than a frame, but for everything else, it just adds async for sth that is actually CPU bound
Can we at least have an option to turn wsam support off?
I don't see WSAM support as a defining feature of this library. So arbitrarily neutering it to be single threaded doesn't seem like a reasonable design decision.
??? Sorry, but this comment makes little sense.
OpenGL (as far as I'm aware) only runs on 1 thread. You can still spawn new threads and do calculations in there if you want. No changes in macroquad/miniquad have to be made to support this.
Making non-Wasm use tokio will require quite a bit of effort, it may not be worth it, considering you can add tokio support outside this crate.
Is it even possible? As far I understand it, systems like wayland use a callback system similarly to how it works on browsers. So, you would still need the generator like design on those platforms. It does not sound like a good idea to let tokio handle this....