Expand description
Read-optimized concurrent stores for read-heavy, write-rare data.
Terminal UIs are read-dominated: theme colors, terminal capabilities, and
animation clocks are read every frame but changed only on user action or
mode switch. A traditional RwLock or Mutex adds unnecessary contention
on the hot read path.
This module provides ReadOptimized<T>, a trait abstracting over
wait-free read stores, plus three concrete implementations:
| Store | Read | Write | Use case |
|---|---|---|---|
ArcSwapStore | wait-free | atomic swap | Production default |
RwLockStore | shared lock | exclusive lock | Baseline comparison |
MutexStore | exclusive lock | exclusive lock | Baseline comparison |
§Constraints
#![forbid(unsafe_code)]— all safety delegated toarc-swap.T: Clone + Send + Sync— required for cross-thread sharing.- Read path allocates nothing (arc-swap
loadreturns a guard, no clone). - Write path allocates one
Arcper store.
§Example
use ftui_core::read_optimized::{ReadOptimized, ArcSwapStore};
let store = ArcSwapStore::new(42u64);
assert_eq!(store.load(), 42);
store.store(99);
assert_eq!(store.load(), 99);§Design decision: arc-swap over left-right
Both crates provide safe, lock-free reads. arc-swap was chosen because:
- Simpler API — single
ArcSwap<T>vs read/write handle pairs. - Lower memory — one
Arcvs two full copies ofT. - Sufficient for our types —
ResolvedTheme(Copy, 76 bytes) andTerminalCapabilities(Copy, 20 bytes) are tiny; double-buffering gains nothing. - Zero-dependency unsafe — our crate stays
#![forbid(unsafe_code)]; the unsafe is encapsulated insidearc-swap.
The seqlock crate was rejected because its API requires unsafe at the
call site.
Structs§
- ArcSwap
Store - Wait-free reads via
arc_swap::ArcSwap. - Mutex
Store - Exclusive-lock reads via
std::sync::Mutex. - RwLock
Store - Shared-lock reads via
std::sync::RwLock.
Traits§
- Read
Optimized - A concurrent store optimized for read-heavy access patterns.