On Sat, Jul 13, 2024 at 07:40:42 +0700, Robert Elz wrote:
> Please just change this, use the first definition of "next job to
> finish" - and in the case when there are already several of them,
> pick one, any one - you could order them by the time that bash reaped
> the jobs internally, but there's no real reason to do so, as that
> isn't necessarily the order the actual processes terminated, just
> the order the kernel picked to answer the wait() sys call, when
> there are several child zombies ready to be reaped.
This would be greatly preferred, and it's how most people *think*
wait -n currently works.
The common use case for "wait -n" is a loop that tries to process N jobs
at a time. Such as this one:
greg@remote:~$ cat ~greybot/factoids/wait-n; echo
Run up to 5 processes in parallel (bash 4.3): i=0 j=5; for elem in
"${array[@]}"; do (( i++ < j )) || wait -n; my_job "$elem" & done; wait
If two jobs happen to finish simultaneously, the next call to wait -n
should reap one of them, and then the call after that should reap
the other. That's how everyone wants it to work, as far as I've seen.
*Nobody* wants it to skip the job that happened to finish at the exact
same time as the first one, and then wait for a third job. If that
happens in the loop above, you'll have only 4 jobs running instead of 5
from that point onward.
