pub fn begin_shutdown() -> Result<bool, RuntimeConfigError>Expand description
Phase 1 of a two-phase shutdown. Publishes the stop, closes admission,
aborts registered tasks, drops queued work, drain-fires timers and wakes
parkers – and never waits. Never, including for a rejected submission
whose destructor is still running on another thread: that wait belongs to
finish_shutdown too.
Ok(true) means the announced stop still owes a wait – registered work
that is still live, or a rejected submission still being destroyed: let
the host loop turn, poll runtime_work_pending until it answers false
(or a bound expires), then call finish_shutdown. Ok(false) means
finish_shutdown has nothing to wait for.
For a host that cannot yield inside shutdown – on the threaded WASI
artifact the call comes from the JS thread, which is also the only thread
that can give a running blocking closure the turn it is waiting for.
Submissions are rejected between the phases, and start must not be
called there: it waits for phase 2 to publish the stop. A second
begin_shutdown before finish_shutdown neither waits nor starts a
second shutdown; it just re-reports runtime_work_pending. Calls of the
two phases do not have to balance: finish_shutdown completes the most
recently announced stop and is idempotent.