|
1 | 1 | //! This module contains the guts of Bevy's entity allocator. |
2 | 2 | //! |
3 | 3 | //! Entity allocation needs to work concurrently and remotely. |
4 | | -//! Remote allocations (where no reference to the world is held) is needed for async primarily for use. |
| 4 | +//! Remote allocations (where no reference to the world is held) is needed for long running tasks, such as loading assets on separate threads. |
5 | 5 | //! Non-remote, "normal" allocation needs to be as fast as possible while still supporting remote allocation. |
6 | 6 | //! |
7 | 7 | //! The allocator fundamentally is made of a cursor for the next fresh, never used [`EntityIndex`] and a free list. |
8 | | -//! The free list is some collection that hold [`Entity`] values that were used and can be reused; they are "free"/available. |
| 8 | +//! The free list is a collection that holds [`Entity`] values that were used and can be reused; they are "free"/available. |
9 | 9 | //! If the free list is empty, it's really simple to just increment the fresh index cursor. |
10 | 10 | //! The tricky part is implementing a remotely accessible free list. |
11 | 11 | //! |
|
18 | 18 | //! That means, we can have a much more efficient allocation scheme, far better than a linked list. |
19 | 19 | //! |
20 | 20 | //! For the free list, the list needs to be pinned in memory and yet grow-able. |
21 | | -//! That's quire the pickle, but by splitting the growth over multiple arrays, this isn't so bad. |
| 21 | +//! That's quite the pickle, but by splitting the growth over multiple arrays, this isn't so bad. |
22 | 22 | //! When the list needs to grow, we just *add* on another array to the buffer (instead of *replacing* the old one with a bigger one). |
23 | 23 | //! These arrays are called [`Chunk`]s. |
24 | 24 | //! This keeps everything pinned, and since we know the maximum size ahead of time, we can make this mapping very fast. |
@@ -48,7 +48,6 @@ use super::{Entity, EntityIndex, EntitySetIterator}; |
48 | 48 |
|
49 | 49 | /// This is the item we store in the free list. |
50 | 50 | /// Effectively, this is a `MaybeUninit<Entity>` where uninit is represented by `Entity::PLACEHOLDER`. |
51 | | -/// This is |
52 | 51 | struct Slot { |
53 | 52 | inner: SyncUnsafeCell<Entity>, |
54 | 53 | } |
@@ -258,7 +257,7 @@ impl FreeBuffer { |
258 | 257 | /// |
259 | 258 | /// # Safety |
260 | 259 | /// |
261 | | - /// [`set`](Self::set) must have been called on this index to initialize the its memory. |
| 260 | + /// [`set`](Self::set) must have been called on this index to initialize its memory. |
262 | 261 | /// There must be a clear, strict order between this call and the previous uses of this `full_index`. |
263 | 262 | /// Otherwise, the compiler will make unsound optimizations. |
264 | 263 | unsafe fn get(&self, full_index: u32) -> Entity { |
@@ -473,10 +472,13 @@ impl FreeCount { |
473 | 472 | success: Ordering, |
474 | 473 | failure: Ordering, |
475 | 474 | ) -> Result<(), FreeCountState> { |
476 | | - self.0 |
| 475 | + match self |
| 476 | + .0 |
477 | 477 | .compare_exchange(expected_current_state.0, target_state.0, success, failure) |
478 | | - .map(|_| ()) |
479 | | - .map_err(FreeCountState) |
| 478 | + { |
| 479 | + Ok(_) => Ok(()), |
| 480 | + Err(val) => Err(FreeCountState(val)), |
| 481 | + } |
480 | 482 | } |
481 | 483 | } |
482 | 484 |
|
@@ -557,7 +559,7 @@ impl FreeList { |
557 | 559 | // SAFETY: This was less then `len`, so it must have been `set` via `free` before. |
558 | 560 | // There is a strict memory ordering of this use of the index because the length is only decreasing. |
559 | 561 | // That means there is only one use of this index since the last call to `free`. |
560 | | - // The only time it the length increases is during `free`, which the caller ensures has a "happened before" relationship with this call. |
| 562 | + // The only time the length increases is during `free`, which the caller ensures has a "happened before" relationship with this call. |
561 | 563 | Some(unsafe { self.buffer.get(index) }) |
562 | 564 | } |
563 | 565 |
|
|
0 commit comments