Struct ChildLock 

pub struct ChildLock(pub LockWithTimeout<Child>);

A wrapper around LockWithTimeout<Child> that synchronizes access to a tokio::process::Child. This allows safe concurrent reads/writes or attempts to kill the child within specified timeouts.

Tuple Fields

0: LockWithTimeout<Child>

Implementations

impl ChildLock

pub fn new(child: Child) -> Self

Wraps a Child in a LockWithTimeout, allowing timed read/write locks on the child handle.

pub fn update(self, new_child: Child) -> Self

Replaces the child handle within this lock. Typically used when restarting or re-spawning the same command.

pub fn clone(&self) -> Self

Clones the internal lock (i.e., Arc-based duplication). This does not duplicate the child process, only the lock mechanism that references it.

pub async fn kill(&self) -> Result<(), ErrorArrayItem>

Recursively terminates the child’s process group. Sends SIGTERM to all descendant PIDs and then SIGKILL to any that remain, logging progress at Trace level.

Errors

• Returns an ErrorArrayItem on I/O issues or if reaping fails.
• If the child’s PID is invalid, returns an error.

pub async fn try_wait(&self) -> Result<Option<ExitStatus>, ErrorArrayItem>

Non-blocking check for whether the child has already exited.

This calls tokio::process::Child::try_wait under the hood, which performs a waitpid(..., WNOHANG) on our behalf. Unlike a raw kill(pid, 0) signal check, this correctly reports an exited process as no longer running (rather than as a still-existing zombie), and it reaps the process in the same call so it never lingers as a zombie.

Returns

• Ok(Some(status)) if the process has already exited (now reaped).
• Ok(None) if the process is still running.

Errors

• Returns an ErrorArrayItem if the child lock can’t be acquired in time.

pub async fn running(&self) -> bool

Checks if the child is still running – the one true liveness check for a process we hold a real tokio::process::Child handle for.

This reaps via try_wait rather than signaling the PID directly, so an exited-but-unreaped child (a zombie) is correctly reported as not running instead of appearing alive.

A lock-acquisition timeout is treated as “unknown” and reported as still running, so callers don’t tear down a healthy child on transient contention. Any other error (e.g. the OS reporting no such child, which happens if the process was already reaped elsewhere, such as by a concurrent kill()) is treated as “not running”.