Struct CtrlC 

pub struct CtrlC { /* private fields */ }

A handle to the process’s Ctrl+C signal, threaded explicitly through every function that needs to react to it (execute, run_polling_loop, attempt_restore) rather than each calling tokio::signal::ctrl_c() itself.

CtrlC::install must be called exactly once, as early as possible, in the real binary’s startup (crate::run) – never from a function unit tests exercise. run_with_cli’s and commands::tune::run’s test-facing entry points instead default to [CtrlC::never] internally, so the many unit tests that exercise those functions never install a real process-wide signal handler. That matters beyond just those tests: once anything in a process calls tokio::signal::ctrl_c(), the OS’s default “terminate on SIGINT” behavior is gone for the rest of that process, so if any unit test installed a real handler, a developer’s own Ctrl+C meant to abort a hung cargo test run could silently disappear into an idle listener nothing is polling.

pub (rather than pub(crate)) so bhtune-server can name the type as it threads a CtrlC::manual handle through commands::tune::drive for an HTTP-triggered run – see that constructor’s doc comment. CtrlC::signalled itself deliberately stays pub(crate): only code inside this crate (execute/run_polling_loop/attempt_restore) ever needs to observe a cancellation, an external caller only ever needs to trigger one, via a CtrlCHandle.

Implementations

impl CtrlC

pub fn manual() -> (CtrlC, CtrlCHandle)

Returns a fresh (CtrlC, CtrlCHandle) pair for a caller with no real OS Ctrl+C keypress to listen for at all – bhtune-server’s background tune task, which needs an HTTP request (POST /api/runs/{id}/cancel, or graceful shutdown) to be able to trigger the exact same cancellation an interactive Ctrl+C would.

Deliberately not #[cfg(test)]-gated, unlike [CtrlC::never]/[CtrlC::test_pair] above: those exist purely so this crate’s own unit tests can avoid installing a real process-wide signal handler, but manual() never touches tokio::signal/CtrlC::install at all, so calling it from production code any number of times (once per in-flight run) carries none of that risk.