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 !!! :)
