while (( ++job <= joblimit )) ; do
job &
done
while true ; do
wait -n
job &
done
On Wed, Jul 16, 2025, 4:21 PM John Sidles <jasid...@gmail.com> wrote:
> Please let me thank everyone for their kind attention and thoughtful
> remarks on this problem ... I am struggling however to summarize the
> discussion so far ... specifically in regard to workarounds. To date, the
> sole suggested workaround is:
>
> The fix for your case is to insert `wait' without arguments
>
> after the call to mapfile and before the sleep.
>
> That way you ensure that the 'wait -n' waits for the sleep process.
>
>
> Hmmm ... yes, the suggested workaround does patch the minimal working
> example (MWE). But it is NOT a general-purpose workaround.
>
> As a concrete---and common-place---example, I use bash-scripts to run
> (asynchronously) cpu-intensive optical-character-recognition (OCR)
> processes. On my system, optimal cpu-loading is achieved when no more than
> five OCR processes are running. So I initialize an array PIDS with the
> job-ids of the asynchronous OCR processes that presently running. Various
> initialization methods work; the following is a general-purpose one-liner:
>
> mapfile -t PIDS < <(jobs -rp); # initialize PIDS (by any method)
>
> Then at any later time (possibly after further housekeeping tasks),
> and immediately
> prior to launching another (asynchronous) OCR process, issue
>
> JOB_LIMIT=5 ((${#PIDS[@]}<JOB_LIMIT)) || wait -n "${PIDS[@]}";
>
> QUESTION: given an array PIDS containing (cpu-intensive) job-ids, what
> (all-settings?) bash-workaround replaces the above { wait -n "${PIDS[@]}";
> }
> command?
>
> PS: Thank you especially, Chet Ramsey, for the smile-inducing quotes from
> Chaucer and Hippocrates in your email signature. BIOLOGICALS FOREVER !!!
> :)
>
