Skip to main content

Module spawn

Module spawn 

Source
Expand description

Starting a relay target that is not running (#5182, ADR-0034 §1).

Why: milestone tm 1.3.5 criterion (c) wants no resident trusty-analyze or trusty-review daemon, and relaying over UDS wants a bound listener. Both hold only if something makes the target resident at the moment of delivery. Measured, that trade is cheap: #5028 recorded zero webhook deliveries in 14 days, a 191 ms cold start, and a 36.7 s median review — so the spawn is half a percent of the work it precedes.

What: a thin wrapper over trusty_common::uds::UdsServiceSupervisor, the supervisor promoted from trusty-memory’s Bm25Supervisor in #5089 step 2. Writing a second supervisor here would re-earn the scars of #2845, #2846 and #5085 — the serialised spawn gate, the live-child cap, the socket-decides- liveness rule — so this only supplies the per-service parts: which binary, which argv, and the timing budget.

Test: webhook/tests.rsspawn_*.

Structs§

TargetSupervisor
Supervises the two webhook relay targets on demand.

Constants§

ENV_EXTERNAL_TARGETS
Environment variable that hands target lifecycle back to the operator.
LISTEN_SUBCOMMAND
Subcommand every relay target implements to serve its socket.

Functions§

target_binary_name
The binary that serves a given {source} route segment.

Type Aliases§

SharedSupervisor
Shared handle a super::relay::UdsRelay holds.