Module layout 

Where each pipeline thread runs and how it waits there: the --cores layout.

A layout is one Placement per pipeline thread — a core and a WaitStrategy — parsed from --cores, resolved against the transport, and checked before any thread is spawned. --cores is the only place a wait policy is stated, so there is one spelling of every layout and nothing for a second flag to override. The check exists because the two halves of a placement constrain each other across threads: a busy-spinning thread needs its core to itself, and two threads that share a core must both yield, or the one waiting sits queued behind the one spinning for a full scheduler slice on every hand-off. A node refuses to start with a layout that breaks that rule rather than running slowly and unpredictably.

--cores names each thread (journal-seq=1,matching=2,…) rather than listing cores by position. A positional list can only ever grow at its end and can never lose an entry: dropping one re-reads every later core as its neighbour’s, and the result usually still parses. A named entry says which thread it places, so a misspelt, repeated or missing name is refused, a retired thread is simply an unknown one, and a thread added later is one more name rather than one more position.

Structs

PipelineCores

Core assignments for pipeline threads, each with its wait policy.

Placement

Where one pipeline thread runs and how it waits there.

Enums

ReaderThread

What the reader entry of --cores pins on a given transport. The two threads wait differently, and one of them cannot take a policy at all.