Concurrency, Async, and Pipeline Pressure

RecordingStream is Send + Sync; clones from many application threads feed one linearized batching pipeline. Per-producer order is preserved, while a global order between unrelated threads is intentionally not promised.

The batcher and sink-forwarder have dedicated OS threads. This isolates row coalescing, Arrow work, compression, and potentially blocking sinks from the caller’s hot path. Rerun also uses Rayon for parallel CPU transformations, which is why its public docs warn against calling log while holding a standard mutex: work stealing plus an external lock can create a dependency cycle.

The important capacity is bytes, not message count. One image may outweigh thousands of scalar logs. re_quota_channel computes SizeBytes, admits data under a shared byte budget, and wakes blocked senders when receive releases those bytes. An oversized single message is allowed only after the channel empties.

Viewer networking and background services use async Rust on native builds. re_async::AsyncRuntimeHandle spawns Send futures on a supplied Tokio runtime, but uses the browser’s local executor for possibly non-Send futures under WebAssembly.

The UI itself is immediate-mode and primarily owner-threaded. Concurrency feeds it immutable-ish chunks, caches, and GPU work rather than concurrently mutating egui state from every producer.