One feature that has added a notable amount of the complexity to bevy_tasks is how !Send constraints within Bevy's ECS are handled. These resources force the task to only be run from a specific thread, but may be scheduled from any other thread. bevy_tasks addresses this by creating a thread-local ThreadExecutor and then weaving it in Scope tasks' polling. This is further refined in bevyengine/bevy#20331 into a dedicated per-thread queue that is separately polled by every thread when looking for new work.
For Forte to be viable as a replacement for bevy_tasks, there needs to be some support for this feature, ideally with a API as follows:
// `thread_id` may denote a Worker or even a temporary worker that periodically joins the ThreadPool.
// This function should panic if a non-worker thread is provided.
impl Worker {
pub fn spawn_to_thread<F: FnOnce()>(thread_id: ThreadId, f: F);
pub fn spawn_future_to_thread<T, Fut: Future<Output = T>>(thread_id: ThreadId, future: Fut) -> Task<T>;
}
impl<'a> Scope<'a> {
pub fn spawn_to_thread<F: FnOnce(Scope<'a>)>(thread_id: ThreadId, f: F) -> Task<T>;
pub fn spawn_future_to_thread<T, Fut: Future<Output = T>>(thread_id: ThreadId, future: Fut) -> Task<T>;
}Since these jobs can only be run on the target thread, these jobs ideally should be prioritized over other Send jobs that end up in the same thread's queue.
One feature that has added a notable amount of the complexity to
bevy_tasksis how!Sendconstraints within Bevy's ECS are handled. These resources force the task to only be run from a specific thread, but may be scheduled from any other thread.bevy_tasksaddresses this by creating a thread-localThreadExecutorand then weaving it in Scope tasks' polling. This is further refined in bevyengine/bevy#20331 into a dedicated per-thread queue that is separately polled by every thread when looking for new work.For Forte to be viable as a replacement for
bevy_tasks, there needs to be some support for this feature, ideally with a API as follows:Since these jobs can only be run on the target thread, these jobs ideally should be prioritized over other
Sendjobs that end up in the same thread's queue.