72f096c91e
# Objective - Contributes to #15460 ## Solution - Added the following features: - `std` (default) - `async_executor` (default) - `edge_executor` - `critical-section` - `portable-atomic` - Added [`edge-executor`](https://crates.io/crates/edge-executor) as a `no_std` alternative to `async-executor`. - Updated the `single_threaded_task_pool` to work in `no_std` environments by gating its reliance on `thread_local`. ## Testing - Added to `compile-check-no-std` CI command ## Notes - In previous iterations of this PR, a custom `async-executor` alternative was vendored in. This raised concerns around maintenance and testing. In this iteration, an existing version of that same vendoring is now used, but _only_ in `no_std` contexts. For existing `std` contexts, the original `async-executor` is used. - Due to the way statics work, certain `TaskPool` operations have added restrictions around `Send`/`Sync` in `no_std`. This is because there isn't a straightforward way to create a thread-local in `no_std`. If these added constraints pose an issue we can revisit this at a later date. - If a user enables both the `async_executor` and `edge_executor` features, we will default to using `async-executor`. Since enabling `async_executor` requires `std`, we can safely assume we are in an `std` context and use the original library. --------- Co-authored-by: Mike <2180432+hymm@users.noreply.github.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
44 lines
2.7 KiB
Markdown
44 lines
2.7 KiB
Markdown
# Bevy Tasks
|
|
|
|
[](https://github.com/bevyengine/bevy#license)
|
|
[](https://crates.io/crates/bevy_tasks)
|
|
[](https://crates.io/crates/bevy_tasks)
|
|
[](https://docs.rs/bevy_tasks/latest/bevy_tasks/)
|
|
[](https://discord.gg/bevy)
|
|
|
|
A refreshingly simple task executor for bevy. :)
|
|
|
|
This is a simple threadpool with minimal dependencies. The main usecase is a scoped fork-join, i.e. spawning tasks from
|
|
a single thread and having that thread await the completion of those tasks. This is intended specifically for
|
|
[`bevy`][bevy] as a lighter alternative to [`rayon`][rayon] for this specific usecase. There are also utilities for
|
|
generating the tasks from a slice of data. This library is intended for games and makes no attempt to ensure fairness
|
|
or ordering of spawned tasks.
|
|
|
|
It is based on [`async-executor`][async-executor], a lightweight executor that allows the end user to manage their own threads.
|
|
`async-executor` is based on async-task, a core piece of async-std.
|
|
|
|
## Usage
|
|
|
|
In order to be able to optimize task execution in multi-threaded environments,
|
|
bevy provides three different thread pools via which tasks of different kinds can be spawned.
|
|
(The same API is used in single-threaded environments, even if execution is limited to a single thread.
|
|
This currently applies to Wasm targets.)
|
|
The determining factor for what kind of work should go in each pool is latency requirements:
|
|
|
|
* For CPU-intensive work (tasks that generally spin until completion) we have a standard
|
|
[`ComputeTaskPool`] and an [`AsyncComputeTaskPool`]. Work that does not need to be completed to
|
|
present the next frame should go to the [`AsyncComputeTaskPool`].
|
|
|
|
* For IO-intensive work (tasks that spend very little time in a "woken" state) we have an
|
|
[`IoTaskPool`] whose tasks are expected to complete very quickly. Generally speaking, they should just
|
|
await receiving data from somewhere (i.e. disk) and signal other systems when the data is ready
|
|
for consumption. (likely via channels)
|
|
|
|
## `no_std` Support
|
|
|
|
To enable `no_std` support in this crate, you will need to disable default features, and enable the `edge_executor` and `critical-section` features. For platforms without full support for Rust atomics, you may also need to enable the `portable-atomic` feature.
|
|
|
|
[bevy]: https://bevyengine.org
|
|
[rayon]: https://github.com/rayon-rs/rayon
|
|
[async-executor]: https://github.com/stjepang/async-executor
|