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