Title: Supported macOS PID reservation for an exited but unreaped direct child I'm designing a process-lifecycle experiment on Apple silicon, initially targeting macOS 26.7.2 (build 25G332). A trusted parent directly launches a foreground child using posix_spawn(). The parent remains alive, exclusively owns reaping, preserves child exit status, and never sets SIGCHLD to SIG_IGN or enables SA_NOCLDWAIT. The parent may send kill(child_pid, SIGKILL) before obtaining the child's terminal status through waitpid(). POSIX.1-2008 §3.295 describes the PID as the last resource released when a process's lifetime ends. Section 4.13 prohibits PID reuse before that lifetime ends. Could Apple DTS clarify the supported macOS contract for this sequence? If the child exits immediately before the kill() call but remains unreaped, is its PID guaranteed not to be reassigned to another process while the original parent retains exclusive reaping authority? Does this guarantee apply to a child created through posix_spawn() on current Apple silicon macOS releases? Are there documented exceptions beyond automatic status disposal, competing reapers and parent termination? What result should the parent expect when kill() targets an already-exited but unreaped child? The design serialises signaling and reaping, and never signals the numeric PID after status consumption. This question concerns identity-safe signal targeting, not whether successful kill() establishes termination. The latter is separately verified using waitpid(). I'm seeking a supported API contract rather than empirical observations or private kernel implementation details. Thank you.

Title: Supported macOS PID reservation for an exited but unreaped direct child

Title: Supported macOS PID reservation for an exited but unreaped direct child

I'm designing a process-lifecycle experiment on Apple silicon, initially targeting macOS 26.7.2 (build 25G332).

A trusted parent directly launches a foreground child using posix_spawn(). The parent remains alive, exclusively owns reaping, preserves child exit status, and never sets SIGCHLD to SIG_IGN or enables SA_NOCLDWAIT.

The parent may send kill(child_pid, SIGKILL) before obtaining the child's terminal status through waitpid().

POSIX.1-2008 §3.295 describes the PID as the last resource released when a process's lifetime ends. Section 4.13 prohibits PID reuse before that lifetime ends.

Could Apple DTS clarify the supported macOS contract for this sequence?

If the child exits immediately before the kill() call but remains unreaped, is its PID guaranteed not to be reassigned to another process while the original parent retains exclusive reaping authority?
Does this guarantee apply to a child created through posix_spawn() on current Apple silicon macOS releases?
Are there documented exceptions beyond automatic status disposal, competing reapers and parent termination?
What result should the parent expect when kill() targets an already-exited but unreaped child?

The design serialises signaling and reaping, and never signals the numeric PID after status consumption.

This question concerns identity-safe signal targeting, not whether successful kill() establishes termination. The latter is separately verified using waitpid().

I'm seeking a supported API contract rather than empirical observations or private kernel implementation details.

Thank you.