`bevy_tasks` cannot be implemented correctly on the web

[NthTensor]

On the web, blocking the main thread is to be avoided: the behavior is browser-specific, but at best it will freeze the UI, and at worst it will crash the page. This means we really shouldn't block anywhere that might possibly run on the browser's main thread. And, unfortunately, because bevy targets single-threaded web deployment, to me it seems like this means effectively the entire code-base must be non-blocking.

This has a few repercussions:

• It's impossible to correctly implement TaskPool::scope without blocking. Currently when single threaded it has a panicking failure case that is impossible to fix.
• Fixing TaskPool::scope would require changing it to return a Future. This may require making much more of our executor and scheduling code into async, due to function coloring.
• There are several other places where we make calls that may potentially block within the engine. Proper web support would require that we either ensure these never block in practice, or swap the blocking calls for async ones.

TaskPool::scope only fails under specific conditions: when all the scope has pending tasks, but they are all asleep (waiting for other futures to complete). When this happens, the scope returns early. Since this is only single-threaded, this does not cause UB, but it does cause a panic when the runtime figures out that it's missing the results it expected from the incomplete tasks.

Luckily for us, the issue with TaskPool::scope is rare. You only hit it when you set up a scope with futures that do actually have to wait for meaningful amounts of time, and mostly people don't seem to do that. But it's dreadfully easy to hit when doing complex networking in the browser.

---

Setting scope issue aside, there's a general question of what to do about bevy_tasks. Because bevy aims to be extremely cross-platform, it is also constrained to the least-common denominator of what those platforms support. Unfortunately, bevy_tasks currently does things that just will not work on the web. What should we do about that?

[maniwani]

Would it help if the ECS ran inside a web worker?

On Discord, I recently suggested reworking App into a trait in order to delay world/plugin construction. Maybe it can help with this situation as well.

pub trait App {
    // user implementations should set up an execution environment (e.g. browser event loop), construct
    // a world *at some point* (perhaps in another thread), pass it into `setup`, and start the app
    fn run();

    // user implementations should add their plugins, define their schedules, etc. in here
    fn setup(world: &mut World);
}

I'm not an expert on wasm-bindgen, but if you can delay the world's construction, I think that should enable an architecture where the main thread spawns a web worker thread to host the ECS.

Events from the winit event loop (and window updates from the ECS) would need to be serialized, but the two threads could exchange messages by using postMessage to transfer ArrayBuffer objects. SharedArrayBuffer is not required.

[NthTensor]

Things get a lot better with web-workers, and they are baseline and widely available. Moving the app code off the main thread would be ideal, yeah.

So we would have WebApp, NativeApp and EmbeddedApp that all implemented App and provide scheduling and execution?

[maniwani]

So we would have WebApp, NativeApp and EmbeddedApp that all implemented App and provide scheduling and execution?

I was thinking the App trait would be implemented by the end user.

A plugin crate like bevy_winit could still provide a fn runner<A: App>() function (which can have the platform-dependent behavior) and the App trait could even import one to be its default implementation of run, e.g.

pub trait App {
    fn run() {
        bevy_winit::winit_runner<Self>();
    }
    fn setup(world: &mut World);
}

(Plugin would move into bevy_ecs, that way none of the plugins need to depend on bevy_app, then bevy_app could depend on bevy_winit.)

That being said, after my first comment, it occurred to me that—since the web "threads" would have to communicate using plain-old-data messages in the common case—launching the app as a web worker could be accomplished without making App a trait.

A smaller change might be to simply change winit_runner on web and use wasm-bindgen to expose two entry points to JavaScript (or two wasm binaries), one that sets up the winit event loop and spawns the web worker, and one to be the code ran by the web worker.

[NthTensor]

That all makes sense. It also looks like shared array buffers and wasm atomics are baseline, so we could probably get away with more advanced synchronization with a bit of work. Rust has all the intrinsics we would need.

Would Plugin take a World then?

[maniwani]

Would Plugin take a World then?

Yes, but I guess I veered off-topic on that point.

App, SubApp, Plugin are largely the way they are today because building certain plugins requires access to the render world before the pipelining plugin's finish moves it into the render thread.

Like, AFAIK these APIs are historically tied the dependency chain of bevy_winit -> bevy_render -> bevy_<whatever>.

If add_plugins merely queued the build calls instead of calling build immediately, that would give Bevy an opportunity to sort out their dependencies and build them in topological order.

And Plugin::build could just take World because having an App/SubApp struct wouldn't even be necessary.

The bevy_render plugin could store the render world as an entity in the main world, and its dependents could just query for that (and then later some startup system or observer could yeet it into the render thread).