Path: csiph.com!xmission!news.snarked.org!news.linkpendium.com!news.linkpendium.com!panix!usenet.stanford.edu!not-for-mail
From: Earnestly <zibeon@googlemail.com>
Newsgroups: gnu.bash.bug
Subject: Re: How does this wait -n work to cap parallelism?
Date: Mon, 29 Jul 2019 21:27:41 +0100
Lines: 26
Approved: bug-bash@gnu.org
Message-ID: <mailman.194.1564432067.1985.bug-bash@gnu.org>
References: <20190729181242.GB2032@teapot> <20190729202741.GD2032@teapot>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
Mail-Followup-To: Earnestly <zibeon@googlemail.com>, bug-bash@gnu.org
Content-Disposition: inline
In-Reply-To: <20190729181242.GB2032@teapot>
User-Agent: Mutt/1.12.1 (2019-06-15)
Precedence: list
Xref: csiph.com gnu.bash.bug:15269

On Mon, Jul 29, 2019 at 07:12:42PM +0100, Earnestly wrote:
> The question is about how the example works in order to maintain
> parallelism capped at num_proc.

Thanks to emg on #bash for explaining how what is essentially going on.
Bash essentially maintains a list of completed jobs until wait -n
is called and removes one of those completed jobs.  Bash then adds another
job according to the loop I used.

After the "slow" phase of my synthetic code it just so happens that
these jobs are removed and new ones are added rapidly.

And so the jobs are added and then removed accordingly but is never
allowed to exceed "nproc" because wait -n is always called thereafter.

> Below I've provided a synthetic scenario which hopefully highlights my
> (and others) confusion.

It was because of this that I trapped my mind.  Because I was watching
top I concluded that once a job had ended, bash itself would also do
likewise and discard it.  I wasn't able to consider that bash might
maintain a list of *completed* jobs for which subsequent 'wait' calls
would remove.

Sorry for the noise.