On Sun, Jan 28, 2024 at 10:26:27PM -0500, Dale R. Worley wrote: > The man page doesn't make clear that if you don't specify "-n" and do > supply ids and one of them has already terminated, you'll get its status > (from the terminated table); the wording suggests that "wait" will > always *wait for* a termination.
This might be a result of C programmers who already know the semantics of wait(2) writing documentation which assumes the reader *also* knows these semantics. wait(2) and its brethren return immediately if the process in question has already terminated. It's how you reap the zombie and free up the process table slot, while also retrieving its exit status. If it's not already dead, then wait(2) blocks until death occurs. The shell's "wait" command is meant to mimic this behavior, at its core. There are some differences, however -- notably, the shell aggressively reaps zombies and stores their exit statuses in memory, revealing them to you in the event that you call "wait". Normally this change is invisible, but if you were *counting* on the zombie to be there, holding on to that PID, preventing it from being reused until you could observe the death and react to it, then you're screwed. Don't use the shell for this. Anyway... a script writer who has a basic familiarity with wait(2) and who reads about "wait -n" will probably assume that wait -n will return immediately if a child process has already terminated and hasn't been "pseudo-reaped" by a previous "wait" command yet. If three children have terminated, then the next three "wait -n" commands should return immediately, and the fourth should block (assuming a fourth child exists).
