1 |
On Sunday 03 June 2012 18:16:30 Zac Medico wrote: |
2 |
> On 06/02/2012 10:08 PM, Mike Frysinger wrote: |
3 |
> > # @FUNCTION: _multijob_fork # @INTERNAL # @DESCRIPTION: # Do the |
4 |
> > actual book keeping. _multijob_fork() { [[ $# -eq 1 ]] || die |
5 |
> > "incorrect number of arguments" |
6 |
> > |
7 |
> > local ret=0 [[ $1 == "pre" ]] && : $(( ++mj_num_jobs )) |
8 |
> > if [[ ${mj_num_jobs} -ge ${mj_max_jobs} ]] ; then |
9 |
> > multijob_finish_one |
10 |
> > ret=$? |
11 |
> > fi |
12 |
> > [[ $1 == "post" ]] && : $(( ++mj_num_jobs )) |
13 |
> > return ${ret} |
14 |
> |
15 |
> The "pre" logic seems wrong. Consider an initial state of |
16 |
> mj_num_jobs=0 and mj_max_jobs=1. It will increment mj_num_jobs to 1, |
17 |
> so [[ 1 -ge 1 ]] is true, and then call multijob_finish_one even |
18 |
> though no jobs have started yet? Wouldn't that deadlock |
19 |
> multijob_finish_one, as it waits for a reply from a job that doesn't |
20 |
> exist yet? |
21 |
|
22 |
yes, i inverted the cases in this func |
23 |
-mike |