Expand description
§Yaws Slabbable trait
Put a slab into it or Yaws oriented trait requirement for slab implementation. Slabbable is the trait for storage slab-slotmaps for the purpose of keeping the underlying request data alive when kernel is either modifying or keeping a reference of the said data through raw pointers.
This trait is opinionated into purpose of network server proramming that may have high and low load periods with ramp-up and downs.
The underlying implementation does not need to be Sync or Send and typically should live within one thread only requiring no synchronisation / atomics.
The user of the slab-slotmap must guarantee that the owned slotmap itself is not dropped whilst guaranteeing the items inside are not moving or dropped.
§Required Guarantees
The slab-slotmap implementing this trait must:
- Keep the memory addresses stable as-in self-referential structs
- Provide free slot and upon freeing the slot must be re-usable
- Lookable key by usize that can be copy-referenced without pointer access
- Should not leak memory beyond the fixed capacity max.
§Desired Properties
A. Fast random access via key that is usize B. Occupying takes a sequential usize id C. Not re-using sequential usize id until it is recycled at usize::MAX D; Ability to free-up memory e.g. in acses of ramp-up / down high/low loads. E. Minimal memory usage for free slots
Structs§
- Reserved
Slot - Reserved marked for any slot that can be taken later.
Enums§
- Slabbable
Error - All implementations should use the harmonized error type. Slabbable error types are shared across the implementations. Every implementation must use the shared error type so the implementation can be changed easily around without switching error type.
Traits§
- Slabbable
- See module documentation of guarantees needed.