wasm_subsup (wasm v0.2.1)

View Source

One 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

child(Name, Strategy, Kids)

-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.

init/1

start_link(Name, Strategy, Kids)

-spec start_link(atom(), supervisor:strategy(), [module()]) -> supervisor:startlink_ret().