Render App systems are blocking the Main app's primary thread

[james7132]

Bevy version

main (f8fd93f)

What you did

I ran cargo run --profile stress-test --features trace_tracy --example many_cubes and viewed the trace in Tracy.

What went wrong

I was expecting that no blocking systems from the render app would block the main app from progressing.

In this screenshot, prepare_windows is blocking UpdateAssets from terminating. Delaying it from terminating and blocking PreUpdate and subsequent schedules.

We currently do not schedule tasks from the ComputeTaskPool onto the render app thread, it may be a good idea to avoid doing so with all dedicated app schedule threads.

[hymm]

This is the non send data issue. Prepare Windows has to run on main thread because of that. Will be fixed by #9122.

[hymm]

I think prepare_windows might only need to run on main thread for ios. Someone should survey the winit api's, we're using and if they're all ok, add a conditional compiling to NonSendMarker.

i.e. a lot of the docs here https://docs.rs/winit/latest/winit/window/struct.Window.html say that these api's can only be called from main thread on ios.

[daxpedda]

i.e. a lot of the docs here https://docs.rs/winit/latest/winit/window/struct.Window.html say that these api's can only be called from main thread on ios.

This has been addressed in rust-windowing/winit#2985 and rust-windowing/winit#3045.

Though keep mind that functions that return values might block the calling thread until these values are returned.

[jmintb]

Can I have a go at this issue? :)

[alice-i-cecile]

@jmintb absolutely; let us know what you find out!