Module bounded_child 

One child program run with a time bound and output caps, through files instead of pipes. What: Run one child program to completion with a time bound and output caps: its input comes from a file, its two outputs go to files, and the parent polls it. Why: The Markdown policy starts the linter once per candidate, and a child that hangs, floods its output or exits early must never hang or exhaust the wrapper. Files instead of pipes need no reader or writer threads: a child that stops reading its input cannot block the parent, a child that writes more than the cap is stopped when the parent sees the file grow past it, and a grandchild that keeps an output open cannot delay the parent once the child itself has exited. Every file is an anonymous temporary file that the operating system removes when it is closed.

In TS you’d write (pseudocode):

// const run = await runBoundedChild({ executable, args, cwd, env, input, timeoutMs, maxStdout, maxStderr });

Structs

ChildLimits

What: The bounds of one child. usize is an unsigned size in bytes. #[derive(...)] generates copying, debug printing and ==. Why: The caller chooses them, so tests can use bounds small enough to reach quickly.

ChildRequest

What: Everything one child needs. 'a names how long the borrowed parts last; &[(OsString, OsString)] is the complete environment, as name and value pairs. Why: The child gets exactly this environment and nothing inherited by accident.

FinishedChild

What: A child that ran to its end within its bounds, with what it wrote. Why: Interpreting the output is the caller’s job; this only reports it exactly.

Enums

ChildExit

What: How a finished child ended: its exit code, or the signal that ended it. Why: A child ended by a signal has no exit code, and the message must say which.

ChildFailure

What: Why a child produced no usable result. String carries the operating system’s own words where it gave any. Why: Each cause gets its own sentence for the person who ran the command.

Functions

run_bounded_child

What: Run the child of request to its end, or stop it at its bound or its cap. Why: See the module comment. The environment is cleared first, so the child sees exactly the pairs the caller passed.