You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We're investigating using rayon as Bevy's thread pool and scheduler, and part of that requires being able to schedule futures onto the task pool. This has been partially doable with the suggested implementations in the discussion in #679, but we're running into issues where futures::block_on equivalents cannot yield to the thread pool in a way that will put the thread to sleep if there is no available work, nor a way to, on-demand, wake that specificthread back up. futures_lite::block_on and it's variants park the thread using parking or the std equivalent in std::thread::park, but rayon does not expose any option for this level of control. Using the aforementioned options for parking the thread leads to excessive CPU usage and contention, likely due to conflicting with rayon's internal state of how threads should be managed.
A yield_sleep or yield_park equivalent that hooks into the internal thread sleeping state when called, and a corresponding data type that we can wrap as a Waker would be really useful here.
The text was updated successfully, but these errors were encountered:
pubstructParker;pubstructUnparker;implParker{/// Either does one job, or does an additional round of polling via Sleep, eventually putting the thread to sleep, blocking the/// thread until woken up by rayon or the provided Waker.pubfnyield_or_sleep(&self) -> Yield{}}// The converted Wakes up the paired thread.implFrom<Unparker>for std::task::Waker{
...
}/// Linked to WorkerThread::currentpubfnpair() -> (Parker,Unparker){}
If this is too much to expose to a public interface, it's probably fine to also just have this internally inside rayon_core to make a potential rayon_core::futures::block_on as an equivalent to futures_lite::futue::block_on.
We're investigating using rayon as Bevy's thread pool and scheduler, and part of that requires being able to schedule futures onto the task pool. This has been partially doable with the suggested implementations in the discussion in #679, but we're running into issues where
futures::block_on
equivalents cannot yield to the thread pool in a way that will put the thread to sleep if there is no available work, nor a way to, on-demand, wake that specificthread back up.futures_lite::block_on
and it's variants park the thread usingparking
or the std equivalent instd::thread::park
, but rayon does not expose any option for this level of control. Using the aforementioned options for parking the thread leads to excessive CPU usage and contention, likely due to conflicting with rayon's internal state of how threads should be managed.A
yield_sleep
oryield_park
equivalent that hooks into the internal thread sleeping state when called, and a corresponding data type that we can wrap as aWaker
would be really useful here.The text was updated successfully, but these errors were encountered: