Struct SignalGuard 

pub struct SignalGuard { /* private fields */ }

What: Owns the relaying handlers for its lifetime. Install one guard, run the Git child through it, then drop it after cleanup. Why: Dropping it restores the previous dispositions, so a signal after cleanup behaves as it did before.

In TS you’d write (pseudocode):

using guard = SignalGuard.install(); const outcome = await guard.runChild(command);

Implementations

impl SignalGuard

Methods over an installed guard.

pub fn install() -> Result<Self>

What: Install the relaying handlers. Fails when another guard is already active in this process. Why: The handlers are process-wide, so a second guard would record the first one’s handler as the old disposition.

In TS you’d write (pseudocode):

static install(): SignalGuard // throws when already installed

pub fn run_child(&self, command: &mut Command) -> Result<ChildOutcome>

What: Start command, wait for it while relaying signals, and return how it ended. The guard does not exit the process; the caller releases its locks and removes its state, then exits. Why: Signals that arrived before the child started are relayed as soon as it has a PID.

In TS you’d write (pseudocode):

async runChild(command: SpawnOptions): Promise<ChildOutcome>

Trait Implementations

impl Drop for SignalGuard

Available on Unix only.

Restore the previous dispositions and release the process-wide slot.

fn drop(&mut self)

What: Restore the saved dispositions and clear the active flag. Why: The next guard, or the process default after the guard, must see the original handlers.

In TS you’d write (pseudocode):

[Symbol.dispose]() { restore(saved); }

fn pin_drop(self: Pin<&mut Self>)

🔬This is a nightly-only experimental API. (pin_ergonomics)

Execute the destructor for this type, but different to Drop::drop, it requires self to be pinned.