-
-
Notifications
You must be signed in to change notification settings - Fork 1
Buffered forks: taps that consume at their own rate #2
Copy link
Copy link
Open
Labels
enhancementNew feature or requestNew feature or requestsponsorableA capability target open for sponsorship -- lands open, proven by its exampleA capability target open for sponsorship -- lands open, proven by its example
Description
Activity
Metadata
Metadata
Assignees
Labels
enhancementNew feature or requestNew feature or requestsponsorableA capability target open for sponsorship -- lands open, proven by its exampleA capability target open for sponsorship -- lands open, proven by its example
A fork today requires every consumer to accept at line rate (a sink never stalls its source — the rule exists so an observer cannot corrupt the image path). A buffered fork relaxes that honestly: a tap with declared elasticity — a preview scaler, a histogram reader — consumes at its own rate through a bounded buffer, and the bound is part of the contract.
Done means: an example with a deliberately slow tap that provably cannot stall the main path, plus the refusal case — a tap whose declared bound the stimulus exceeds fails loudly at the boundary, not silently by dropping data.
What it unlocks downstream: preview paths, histogram taps and debug streams alongside the full-rate image path, with the elasticity stated in the design rather than discovered in the lab.
This is a sponsorable capability target (see the README's funding section). Sponsored work lands in the open tree immediately, MIT like everything else — sponsorship buys ordering and named credit, not exclusivity. Scope by email: s.rabykin@gmail.com.