Keyed tumbling windows, watermark-and-buffer style — the conservative-shaped OPPONENT
to Examples.KeyedWindow, for the eager-vs-buffered stream experiment (Phase 5).
Same engine, same GVT, same fossil collection, same committed result. The ONLY difference from KeyedWindow is WHERE the per-event compute runs relative to the horizon:
- KeyedWindow (eager): folds and pays
computeinhandle_event, ABOVE GVT. It is speculative — a rollback throws the fold away and re-runs it. At the watermark the answer already exists, socommit/2is a pointer dereference. - BufferedWindow (this):
handle_eventonly APPENDS to a per-window buffer — no fold, no compute. A rollback just truncates the buffer (via the state snapshot), costing nothing to undo. ALL compute happens incommit/2, below GVT, past the horizon — once per event, never rolled back, as a post-watermark burst.
Both are mechanically optimistic (both speculate and roll back). This is not conservative execution; it is the buffer-until-watermark strategy on the optimistic engine. The trade it isolates: eager wastes compute on rollback but has a flat commit; buffered wastes nothing but pays a commit burst that grows with the window backlog.