Found dogfooding rivet 0.5.0 (movebit rewrite, macOS): the staged host process does not respond to SIGTERM — the embedded Racket CS runtime seems to absorb it — so the process only dies via SIGKILL. Consequences: hosts that persist state on exit (flush stats, save window placement) only run that path via an explicit in-app Quit; OS logout, launchd kills, and kill <pid> all bypass it. Same presumably applies to the WinRT/GTK hosts' equivalent signals.
Repro: build any scaffold app, run .rivet/stage/RivetHost, kill -TERM <pid> — process survives; kill -KILL ends it.
Suggestion: first-party shutdown plumbing: hosts install a default SIGTERM/SIGINT handler that (1) runs a backend-side shutdown hook (a sibling of rivet/system's install-crash-hook! — e.g. install-shutdown-hook! or an RPC the host calls before exiting), (2) then exits. Apps then get one reliable place to flush. Until then, apps must install their own signal handlers, which is easy to get wrong alongside the embedded runtime.
Found dogfooding rivet 0.5.0 (movebit rewrite, macOS): the staged host process does not respond to SIGTERM — the embedded Racket CS runtime seems to absorb it — so the process only dies via SIGKILL. Consequences: hosts that persist state on exit (flush stats, save window placement) only run that path via an explicit in-app Quit; OS logout, launchd kills, and
kill <pid>all bypass it. Same presumably applies to the WinRT/GTK hosts' equivalent signals.Repro: build any scaffold app, run
.rivet/stage/RivetHost,kill -TERM <pid>— process survives;kill -KILLends it.Suggestion: first-party shutdown plumbing: hosts install a default SIGTERM/SIGINT handler that (1) runs a backend-side shutdown hook (a sibling of
rivet/system'sinstall-crash-hook!— e.g.install-shutdown-hook!or an RPC the host calls before exiting), (2) then exits. Apps then get one reliable place to flush. Until then, apps must install their own signal handlers, which is easy to get wrong alongside the embedded runtime.