Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #14820 > unrolled thread
| Started by | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| First post | 2018-11-14 10:25 -0500 |
| Last post | 2018-11-14 10:25 -0500 |
| Articles | 1 — 1 participant |
Back to article view | Back to gnu.bash.bug
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Strange behaviour from jobs -p in a subshell Greg Wooledge <wooledg@eeg.ccf.org> - 2018-11-14 10:25 -0500
| From | Greg Wooledge <wooledg@eeg.ccf.org> |
|---|---|
| Date | 2018-11-14 10:25 -0500 |
| Subject | Re: Strange behaviour from jobs -p in a subshell |
| Message-ID | <mailman.4036.1542209157.1284.bug-bash@gnu.org> |
> >>> Consider the following script. While the 3 sleeps are running, both jobs
> >>> -p and $(jobs -p) will print 3 PIDs. Once the 3 children are finished,
[...]
... hey, I think I just figured out the GOAL!
You want to run a whole bunch of jobs in parallel, but only 3 at a
time. Right? There are some solutions for that at
<https://mywiki.wooledge.org/ProcessManagement> (Advanced questions #4).
Our bot in IRC also suggests this example:
parallel() {
local workers=$1 handler=$2 w i
shift 2
local elements=("$@")
for (( w = 0; w < workers; ++w )); do
for (( i = w; i < ${#elements[@]}; i += workers )); do
"$handler" "${elements[i]}"
done &
done
wait
}
parallel 5 md5 *.txt
Some of the examples on the wiki page have a stricter guarantee of
maintaining the number of jobs when their durations are unpredictable,
but I include the above example for completeness. Choose whichever
solution you like best.
Back to top | Article view | gnu.bash.bug
csiph-web