_flush were made async or threaded without the immutable memtable fixDate: 2026-05-29
Time: 14:22
The observations provided give me what I need — the full _flush path is visible through the grep results. Let me piece together the critical analysis.
log-structured-merge-tree/lsm.py:scan — The merge logic across memtables, immutable memtables, and SSTables reveals the full read-path priority orderlog-structured-merge-tree/lsm.py:compact — Compaction reads SSTables via scanall, and would also miss data during an async flush if immutable memtables aren't consultedlog-structured-merge-tree/testlsm.py — Tests use memtablethreshold=2 or 3 to force flushes; check whether any test would catch the async racewal-vs-immutable-memtable-recovery — The WAL provides crash recovery but not concurrency safety — understand the distinct roles of WAL replay (line 30) vs immutable memtable readshash-index-storage/bitcask.py — Lines 196-204 show a similar immutable/active split for compaction in Bitcask, but applied to file segments rather than memtableslsm-flush-not-using-immutable-list — flush assigns frozen = self.memtable but never appends it to self.immutablememtables, relying on synchronous execution to avoid a read visibility gaplsm-read-path-checks-immutable-memtables — get() at line 254 and scan() at line 286 already iterate self.immutablememtables, so the read-path infrastructure for concurrent flushes exists but is unusedlsm-memtable-swap-is-reference-not-copy — Line 307 frozen = self._memtable captures a reference to the SortedDict, not a deep copy, meaning concurrent mutation of the dict would be unsafe without synchronizationlsm-flush-synchronous-invariant — The correctness of the LSM tree depends on _flush completing (memtable swap through SSTable registration) without any interleaved read or write operations