dangernoodle-io / breadboard / 31070224769

97%

push

github

feat: lock bb_data_http's shared EVENT ring for a second push_pump() writer (B1-1450) (#1239)

Guard the shared EVENT ring's generation DECISION with a claim/render/
commit-or-revoke protocol under a short portMUX critical section
(s_event_ring_mux), not merely the final push -- review found a
push-only lock still let two concurrent bb_data_http_push_pump()
callers both decide to render+push the same (key, generation),
producing a genuine double-delivery (ring entries carry no
generation, so there is no downstream dedup). Per key: claim the
generation under lock BEFORE render_fn runs (so only one caller ever
wins the right to render+push it); render_fn stays entirely unlocked
(it can block); on render success, COMMIT re-checks the claim is
still current (compare-and-discard) before pushing -- a slow
render_fn that returns success after a newer concurrent claim has
already committed fresher state is discarded rather than pushed,
since render_fn's own contract is to render the key's current value,
not a frozen per-generation snapshot, so a stale-but-successful
render can easily carry content a newer push already delivered; on
render failure, REVOKE symmetrically compare-and-restores, leaving a
newer concurrent claim alone instead of clobbering it. This folds
the no-render_fn degrade-and-advance path into the same claim step,
so there is exactly one write site for the generation marker, always
locked. Matches the espidf backend's existing s_slots_mux/
s_ws_slots_mux portMUX discipline; host build compiles the lock to a
no-op, consistent with the single-threaded host test harness.

Also ties the event ring's max_entry_bytes and push_pump()'s stack
buffer to one shared macro (BB_DATA_HTTP_EVENT_ENTRY_MAX) and
documents why that equality, plus the ring's EVICT_OLDEST/max_age=0
policy, keep bb_queue_push() free of its own blocking log calls while
the critical section is held.

push_pump()'s public doc documents the resulting protocol precisely:
what COMMIT a... (continued)

8534 of 9074 branches covered (94.05%)

Branch coverage included in aggregate %.

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

14279 of 14434 relevant lines covered (98.93%)

2592.55 hits per line