dangernoodle-io / breadboard / 28565678360

100%

push

github

refactor(bb_event_routes): back SSE static pools with bb_pool in a private arena (B1-478 PR E, B1-476) (#656)

- redesign per firmware review: replace the bb_pool SLOTS free-list with
  index-addressed bb_arena-backed fixed arrays for the SSE-private
  payload+entries bundle (bb_event_routes_common.c) and the ESP-IDF-only
  stack+tcb bundle (bb_event_routes_espidf.c) — a shared free-list let any
  freed slot go to any acquirer (non-atomic w.r.t. the client-slot CAS),
  which is unsafe for SSE's index-stable ownership model
- client slot i (the index the existing CAS client-slot loop assigns
  atomically) deterministically owns bundle[i] for the arena's lifetime —
  no acquire/release, no free-list, no shared mutable pool state; the CAS
  claim already serialises ownership of index i
- both bundle arenas are initialized eagerly (bb_arena_init + one
  bb_arena_alloc for the whole fixed array) at component init rather than
  lazily on first connect, removing the per-connect TOCTOU
- static backing buffers are aligned to _Alignof(max_align_t) (not a
  literal 16), sized from MAX_CLIENTS * sizeof(bundle) plus a documented
  flat header allowance (not a magic constant), with a _Static_assert
  guarding against size_t overflow in that computation; bb_arena_init/
  bb_arena_alloc are therefore provably unreachable-on-failure and use
  assert() (LCOV_EXCL_BR_LINE) instead of a branch + return, eliminating
  the uncovered init-failure branch
- on disconnect there is nothing to "release" — the bundle is index-owned
  for the arena's lifetime; the client slot is freed by the existing CAS
  free (unchanged), removing the alloc-failure bb_pool_release rollback
  branch that was previously uncovered
- zero per-connection malloc preserved on both paths; STATIC_POOL Kconfig
  gate and its default (n) are unchanged; pool exhaustion still rejects
  the same way (BB_ERR_NO_SPACE / 503 max_clients); #650 SSE cleanup
  ordering (deregister before client_release) preserved
... (continued)

1840 of 1840 branches covered (100.0%)

Branch coverage included in aggregate %.

8 of 8 new or added lines in 1 file covered. (100.0%)

3172 of 3172 relevant lines covered (100.0%)

1299.38 hits per line