pub(crate) const EVENT_BUFFER_EVENTS: usize = 4;Expand description
How many events the blocking producer may run ahead of the response stream before it waits for the client.
The channel between the two is the only place the parse’s emit rate meets
the client’s read rate. A client that stops reading keeps its connection
until the write-idle timeout closes it (IFC_STREAM_IDLE_TIMEOUT_SECS,
see write_timeout.rs); until then only this bound stops the producer
from queuing every batch of the model on top of the parse’s working set,
which admission does not account for (it charges the UPLOAD size, not the
tessellated output). A full queue parks the producer in blocking_send
(legal there, it runs on a spawn_blocking thread), so a stalled reader
stalls its own parse instead of growing the process.
Four events is two batches: the pipeline emits each batch as a Batch
frame followed by its Progress frame, so the consumer always has one
batch to serialise and one queued behind it while the producer meshes the
next. Nothing is dropped: the producer waits for capacity. A receiver that
goes away makes a parked send return at once, and the next callback sees
tx.is_closed() and cancels.