Replies: 14 comments 27 replies
-
Impact on
|
Beta Was this translation helpful? Give feedback.
-
|
If we want multi-world apps, we basically need them to be |
Beta Was this translation helpful? Give feedback.
-
|
i see. |
Beta Was this translation helpful? Give feedback.
-
|
Even if we spawned the render world in the render thread, we can't pass a Beyond that, extraction is written using systems. Right now, we insert the main world as a resource (literally I don't think the render world extracts from the main world's |
Beta Was this translation helpful? Give feedback.
-
|
thanks for this detailed explanation! |
Beta Was this translation helpful? Give feedback.
-
|
Not sure the "quick" fix is worth it. It'll be adding a lot of code duplication for forwarding all the methods. I'd be more on board if we had delegation. Probably better just to move on to a final solution. Worth mentioning that #6534 is a quick fix to at least close the soundness bug. |
Beta Was this translation helpful? Give feedback.
-
Broader ImpactOutside of The event loop being blocked while we're running the app schedule causes a bunch of problems:
For a quick rundown on where input events come from (in general):
However, if Also, while Footnotes
|
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
This is only a resource temporarily, before the app even starts. We can just move the storage of |
Beta Was this translation helpful? Give feedback.
-
|
Found one more usage. When the https://github.com/bevyengine/bevy/blob/main/crates/bevy_log/src/lib.rs#L149 |
Beta Was this translation helpful? Give feedback.
-
|
also DebugAssetApp. But I imagine that can be turned into a SubApp and whatever solution we use there. |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
I think the only extra thing we'd need to decouple app updates from the main thread is a channel to receive events from the event loop. #[derive(Resource)]
struct Winit {
recv: Receiver<WinitEvent>,
}That can have our |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
For this one, I think we can just make a Linux |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
The problem is that // The following zero-sized types are for applying Send/Sync restrictions to ensure
// consistent behaviour across different platforms. These verbosely named types are used
// (rather than using the markers directly) in the hope of making the compile errors
// slightly more helpful.
//
// TODO: Remove these in favour of using negative trait bounds if they stabilise.
// A marker used to remove the `Send` and `Sync` traits.
struct NotSendSyncAcrossAllPlatforms(std::marker::PhantomData<*mut ()>);PR #6436 aims to solve this by leaking |
Beta Was this translation helpful? Give feedback.
-
|
(reserved in case I missed any) |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
|
cc @NiklasEi |
Beta Was this translation helpful? Give feedback.
-
|
So I think
|
Beta Was this translation helpful? Give feedback.
-
|
#6572 is how I'd support |
Beta Was this translation helpful? Give feedback.
-
|
My RNG types for |
Beta Was this translation helpful? Give feedback.
-
|
A |
Beta Was this translation helpful? Give feedback.
-
Thread-Local ExecutorThis is my main proposal for decoupling
On most targets, we can then move the world(s) off the main thread upfront and proxy any "must run on the ___ thread" operations through an executor. Rather than force the entire system onto the main thread, we can just scope the parts that borrow A system that looks like this: // This system can only run on the main thread.
fn foo(mut x: ResMut<X>, y: NonSend<Y>) {
*x.field = y.func();
}Would be rewritten like this: // This system can run on any thread.
fn foo(mut x: ResMut<X>, main_thread: Res<ThreadLocal<Main>>) {
// Only this closure runs on the main thread.
*x.field = main_thread.run(|tls: &mut NonSendResources| {
let y = tls.get::<Y>();
y.func()
});
}Or, if we preserve more of the existing ergonomics by adding a // This system can run on any thread.
fn foo(mut x: ResMut<X>, main_thread: Res<ThreadLocal<Main>>) {
// Only this closure runs on the main thread.
*x.field = main_thread.run(|y: &Y| y.func());
}TODO: Show example app runner. Change DetectionIf
|
Beta Was this translation helpful? Give feedback.
-
|
how can you access multiple non send resources at the same time in this model? |
Beta Was this translation helpful? Give feedback.
-
We can make the So like this: fn foo(main_thread: Res<ThreadLocal<Main>>) {
main_thread.run(|tls: &mut NonSendResources| {
let (a, mut b, mut c) = tls.get::<(&A, &mut B, &mut C)>();
/* ... */
});
}Or like this: fn foo(main_thread: Res<ThreadLocal<Main>>) {
main_thread.run(|a: &A, b: &mut B, c: &mut C| {
/* ... */
});
}
pub trait NonSendParamFetch<'tls> {
type Item: NonSendParam<Fetch = Self>;
unsafe fn get_param(tls: &'tls UnsafeCell<NonSendResources>, /* other args... */) -> Self::Item;
} |
Beta Was this translation helpful? Give feedback.
-
Bring your own event loopIf you're writing a plugin that spawns its own dedicated thread, then unless something is specifically tied to the main thread, you can avoid The suggested |
Beta Was this translation helpful? Give feedback.
-
|
TODO: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
Use a thread local abstraction and change NonSend to be a marker to run on main threadWe can use a lib like https://docs.rs/thread-local-object/latest/thread_local_object/ to keep storing the NonSend reources in World. Then we just make NonSend something that tells the system to run on the main thread. fn my_system(non_send_res: NonSend<Res<ThreadLocal<MyResource>>>) {
non_send_res.get(| resource | {
// do something with the resource.
});
}
// this could potentially work with components too
fn my_query_system(non_send_q: NonSend<Query<ThreadLocal<MyComponent>>> {
for my_component in &non_send_q {
my_component.get(| my_c | {
// do something with the component
});
}
}There are at least a couple disadvantages to this approach. The lib above doesn't drop the contained value when the ThreadLocal is dropped. Only when the thread is exited. Also this keeps the complexity of scheduling resources in the scheduler rather than moving it out of it like the above recommended method. The advantages are that it keeps the values "owned" by the world and can even work for NonSend Components. edit: Another disadvatage is that the lib I'm using only allows for usize number of ThreadLocal instances ever existing. This is especially a problem because it doesn't reuse it's internal index. i.e. dropping a resource would not free it's index. This could probably be worked around by rolling our own solution though. |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
nothing in this proposal prevents moving the world off the main thread. Things that need the main thread would just need to be initialized before the world gets sent. |
Beta Was this translation helpful? Give feedback.
-
I got the wrong impression then. So the unique pros of each are:
|
Beta Was this translation helpful? Give feedback.
-
|
made a POC of this #6657 as it was easy to adapt from my earlier PR. Not sure which approach I prefer yet. Need to think about it more. |
Beta Was this translation helpful? Give feedback.
-
|
I did some preliminary work on the |
Beta Was this translation helpful? Give feedback.
-
|
I was looking at the Pros:
Cons:
Possible extensions include:
|
Beta Was this translation helpful? Give feedback.
-
|
There are soundness issues in that crate that I would be ok as a user dealing with, but would strongly hesitate to put in another library. And the soundness issues are likely unfixable at the library level as std had issues with a similar api that they eventually moved to the current closure approach. |
Beta Was this translation helpful? Give feedback.
-
|
AFAIK the soundness issues are restricted only to the |
Beta Was this translation helpful? Give feedback.
-
Summary
The
Worldwould be a betterplacetype if thread-local data was kept out of it.Worldowning!Senddata forces us to block the main thread for long periods of time, which prevents useful concurrency. We can resolve this by storing!Senddata separately and exposing aSendproxy for systems to send work to the main thread.Key Terms
winitevent polling loopBeta Was this translation helpful? Give feedback.
All reactions