mirror of https://github.com/bevyengine/bevy synced 2025-02-16 14:08:32 +00:00

History

Zachary Harrold d70595b667 Add `core` and `alloc` over `std` Lints (#15281 ) # Objective - Fixes #6370 - Closes #6581 ## Solution - Added the following lints to the workspace: - `std_instead_of_core` - `std_instead_of_alloc` - `alloc_instead_of_core` - Used `cargo +nightly fmt` with [item level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Item%5C%3A) to split all `use` statements into single items. - Used `cargo clippy --workspace --all-targets --all-features --fix --allow-dirty` to _attempt_ to resolve the new linting issues, and intervened where the lint was unable to resolve the issue automatically (usually due to needing an `extern crate alloc;` statement in a crate root). - Manually removed certain uses of `std` where negative feature gating prevented `--all-features` from finding the offending uses. - Used `cargo +nightly fmt` with [crate level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Crate%5C%3A) to re-merge all `use` statements matching Bevy's previous styling. - Manually fixed cases where the `fmt` tool could not re-merge `use` statements due to conditional compilation attributes. ## Testing - Ran CI locally ## Migration Guide The MSRV is now 1.81. Please update to this version or higher. ## Notes - This is a _massive_ change to try and push through, which is why I've outlined the semi-automatic steps I used to create this PR, in case this fails and someone else tries again in the future. - Making this change has no impact on user code, but does mean Bevy contributors will be warned to use `core` and `alloc` instead of `std` where possible. - This lint is a critical first step towards investigating `no_std` options for Bevy. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>		2024-09-27 00:59:59 +00:00
..
examples	Inverse `missing_docs` logic (#11676 )	2024-02-03 21:40:55 +00:00
src	Add `core` and `alloc` over `std` Lints (#15281 )	2024-09-27 00:59:59 +00:00
Cargo.toml	Generate links to definition in source code pages on docs.rs and dev-docs.bevyengine.org (#12965 )	2024-07-29 23:10:16 +00:00
README.md	Fix common capitalization errors in documentation (#14562 )	2024-07-31 21:16:05 +00:00

README.md

Bevy Tasks

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 as a lighter alternative to 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, 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)