Parallelism, memory, and scheduling.

BoolIR takes a boolean query, splits the inverted index into shards, and runs one Cilk task per shard. Each task intersects or unions postings lists that are read through mmap. The main thread merges the partial doc-id lists before ranking.

Indexing is a streaming BSBI pass: read a batch of documents, emit term-document pairs, sort, and merge runs. The memory ceiling stays fixed even when the corpus is much larger than RAM.

The reranker is the slow part. Retrieval parallelises well; a BERT pass over the top results does not, and it usually dominates latency. Adding cores barely moves it.

Go gives each P a local run queue and steals from other Ps when the queue runs dry. The model is simple. Two things break it in practice: goroutines that block while holding a lock, and counters that share a cache line across Ps.

The first looks like a stalled pipeline. The second looks like a benchmark that gets slower when you add cores. Both are easier to find with a profile than by reading the code.

abdb stores rows in pages and keeps a buffer pool in front of the file system. Reads take a shared page latch; writes take it exclusively. Visibility is decided by per-tuple XMIN/XMAX fields, so readers do not block writers under snapshot isolation.

The bug I kept hitting was not in the visibility check. It was a page latch left held on an error path.

Sylvan uses ptrace to stop and resume a tracee. Breakpoints are int3 instructions patched into the text segment. Before single-stepping, the original byte has to go back; after the step, the breakpoint has to be reinserted.

Most of the code is bookkeeping around waitpid and the states the process is allowed to be in.