Vista generada de dec-0053: Backpressure waker-based segmentado, NUNCA polling (ADAPT from MoQ kio + iroh-live)
docs/decisions/dec-0053-backpressure-waker-based-segmentado-nunca-polling.mdVista generada desde
docs/decisions/dec-0053-backpressure-waker-based-segmentado-nunca-polling.md. No se edita a mano:bun run docs:genla regenera ybun run docs:checkfalla si difiere. El estado aquí es el del model: si discrepa con otra página, manda el model.
| Campo | Valor |
|---|---|
| Estado | LOCKED (migrado de un rNN por gate-3: el fichero no declara estado) |
| Referencia legada | r40-L2 |
| Fichero | docs/decisions/dec-0053-backpressure-waker-based-segmentado-nunca-polling.md |
Enmendado o sustituido por: r46, r60, r61
Por qué importa (del frontmatter del ADR):
native/zig/media-core/sync/backpressure_waker.zig (código real) + citado por r41 (implementación F0.C.1), r42 (spike Cathedral reusa backpressure_waker.zig), r55 §2 D... y AMENDADO por r46 §4.
Nodos del roadmap que lo citan en refs: ninguno.
Páginas de la documentación que lo citan: ninguna todavía.
Leído de docs/decisions/dec-0053-backpressure-waker-based-segmentado-nunca-polling.md, el fichero canónico.
Backpressure waker-based segmentado, NUNCA polling (ADAPT from MoQ kio + iroh-live)
Task.Delay(50ms)) sería una reescritura completa de la contrapresión del sistema, no un toggle de config.waiters_value/waiters_closed/waiters_consumer) podría pensar que es overengineering vs un simple sleep/poll. El contraste explícito con Jellyfin polling NO es inferible del código solo.Task.Delay(50ms) polling (mete jitter, waste CPU). Trade-off: complejidad de waker-lists segmentadas vs simplicidad de polling + jitter constante. La evidencia CODE_VERIFIED de MoQ/iroh-live demostró que el waker-based es O(1) RSS y no jitter.Split de docs/decisions/r40-scheduler-cache-mechanics-harvest-2026-06-30.md (lock r40-L2) durante PASO 7 (2026-07-16). Ver el fichero padre para el contexto completo del pack original.