wasm_subsup (wasm v0.2.1)
View SourceOne subsystem of the runtime, with a restart budget of its own.
wasm_sup used to supervise all five servers directly, which meant they shared
one allowance: intensity 5, period 10 counted restarts across the whole set,
so losing the module cache three times and the keeper twice inside ten seconds
took down the engine, the code slots and the application with them. A stress run
reached exactly that, and the tree it left behind kept answering calls while the
node's page accounting had quietly reset.
A subsystem is the unit that should share a budget, so each one gets a supervisor and the budget lives there. Cache churn can now spend the cache's allowance and nothing else's.
Why one module and not five
The difference between the subsystems is a strategy, a budget and a list of
children. That is data, and writing it out five times would put the shape of the
tree in five files instead of in wasm_sup, where it is worth reading. Each
supervisor is registered under its own name, so the tree still reads the way the
diagram in wasm_sup draws it.
wasm_subsup:child(wasm_code_sup, rest_for_one, [wasm_code_slots, wasm_jit_sup])
Summary
Functions
A child spec for wasm_sup: one subsystem, under a supervisor of its own.
Functions
-spec child(atom(), supervisor:strategy(), [module()]) -> supervisor:child_spec().
A child spec for wasm_sup: one subsystem, under a supervisor of its own.
Kids names the modules to supervise, in start order. Each is started by its
own start_link/0 and is permanent, because every one of them owns state the
rest of the runtime reads.
-spec start_link(atom(), supervisor:strategy(), [module()]) -> supervisor:startlink_ret().