Expand description
Write-ahead-log coalescing via a scoped cork guard.
Each Map insert or remove flushes RocksDB’s write-ahead log to the OS
immediately after the mutation. “Corking” suppresses that per-write flush:
while one or more Cork guards are live, WAL records accumulate in the
in-memory buffer and reach the OS in a single coalesced batch, trading a
syscall per write for one flush per burst.
Corking is purely a backend write-buffering optimization. It does not change application logic and has no observable effect on the database API. A write enters the memtable synchronously within the insert or remove call itself, so reads return the new value whether or not a cork is held; the cork governs only when WAL bytes reach the OS (the crash-durability window and the flush syscall count), never what any reader or caller observes.
Corks are reference-counted on the Engine. Cork::new raises the count
and Drop lowers it, so a guard’s scope delimits the coalescing window;
nested guards compose, and per-write flushing resumes only when the last one
drops.
Structs§
- Cork
- Scoped guard that coalesces write-ahead-log flushes for its lifetime.