Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #15269

Re: How does this wait -n work to cap parallelism?

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> (permalink)
References <20190729181242.GB2032@teapot> <20190729202741.GD2032@teapot>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Trace usenet.stanford.edu 1564432067 28818 209.51.188.17 (29 Jul 2019 20:27:47 GMT)
X-Complaints-To action@cs.stanford.edu
To bug-bash@gnu.org
Envelope-to bug-bash@gnu.org
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=t/1DXgP0qmxotgTOEVx88iaD7Jijg1/d0A7JkRnXRi8=; b=o4iivXg5gErOeIjHysj3ZPFtxeb0fn6T6NYd+yNnBSv5IPzwroR46yWbBg88pl0lH6 l4fPZqtUDO/obx1iZFkeSXlm1mo8p9ioMXc6i/b/9QWHxE2cuguFa33fpkGJ0aaKLdIg EBe7BOD9NZyb+ODlNl/5daZKlztNie+h8seZzRSop+BGpRghdU5zXxxX5jHWAB6yxGw2 /SEmVYZhiSYqE56dTkmWvTer0b1ALLy9AVfxlYMEQ+nw/1AkQJv4fY6xsllyuwZE3ote x01P06s+kxkLyG/XDdHQmS72RAwiYGuX1TgSwn5Z83/0NAzWZ8HoKlCaar3eDuAlrz0l 8Wpw==
X-Google-DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=t/1DXgP0qmxotgTOEVx88iaD7Jijg1/d0A7JkRnXRi8=; b=RE0IS8nEKejJAC2tR1WzOEoaS+80OAGHTZ9N5bBGM7HDJIdzzXgn7YFnSx5XNqyxxG AX8Gk5rF71oa3a607yfZ6IOPSWSZ5H5AK8JbvOMh69+yIM47q0264ntpeTlZ2G7aL2C7 SOfHbLWyuTaLQuQtii1OxIIhEFGSIYULVMqH2Ry31NVWM73jaBBoXsgSHRiaLxfw12Cv sTVhyLltF20llAwQwTaSLUfO4ZF2dEbT1s0pgm1lbpRcV+rVqIKnkZUumeridF/od78r LNPa/uLZNAjvIdO+uuIxN9M/RQpb5mRr4zGcCf68tAqBfUWRfEke0xTnM0k6bJyuBFmw txzA==
X-Gm-Message-State APjAAAXR3zYCecjL06G684D/HXUAhJgVuGh605ACSB9A3p0XtJObA8OD glhlvbfo1SThYebPUffqHw==
X-Google-Smtp-Source APXvYqzNCHyabHdB9G876/QBOjkK3gEO0v2bemLYs1gsiMdh5iORlqHI+x72yQPOa0SB1HSDW9T9XQ==
X-Received by 2002:adf:efc8:: with SMTP id i8mr66188663wrp.220.1564432062700; Mon, 29 Jul 2019 13:27:42 -0700 (PDT)
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)
X-detected-operating-system by eggs.gnu.org: Genre and OS details not recognized.
X-Received-From 2a00:1450:4864:20::42b
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <20190729202741.GD2032@teapot>
X-Mailman-Original-References <20190729181242.GB2032@teapot>
Xref csiph.com gnu.bash.bug:15269

Show key headers only | View raw


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.

Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread


Thread

Re: How does this wait -n work to cap parallelism? Earnestly <zibeon@googlemail.com> - 2019-07-29 21:27 +0100

csiph-web