Re: wait -n misses signaled subprocess

[Greg Wooledge]

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).