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

Reply via email to