Trap not being run for all CHLD signals, 4.3
$ cat parallel-test.bash
function process_job {
sleep 1
}
function main {
typeset -i index=0 cur_jobs=0 max_jobs=6
trap '((cur_jobs--))' CHLD
set -m
while ((index++ < 30)); do
echo -n "index: $index, cur_jobs: $cur_jobs"
set +m
childs=$(pgrep -P $$ | wc -w)
(( childs < cur_jobs )) && echo -n ", actual childs: $childs"
echo
set -m
process_job &
((++cur_jobs >= max_jobs)) && POSIXLY_CORRECT= wait;
done
echo 'finished, waiting for remaining jobs...'
wait
}
main
echo "done"
This works on:
GNU bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)
But on:
GNU bash, version 4.3.11(1)-release (x86_64-pc-linux-gnu)
and
GNU bash, version 4.3.24(1)-release (x86_64-unknown-linux-gnu)
it will around "index: 9" start missing traps (not decrementing cur_jobs):
$ bash-4.3.24/bin/bash parallel-test.bash
index: 1, cur_jobs: 0
index: 2, cur_jobs: 1
index: 3, cur_jobs: 2
index: 4, cur_jobs: 3
index: 5, cur_jobs: 4
index: 6, cur_jobs: 5
index: 7, cur_jobs: 5
index: 8, cur_jobs: 5
index: 9, cur_jobs: 5, actual childs: 4
index: 10, cur_jobs: 5, actual childs: 3
index: 11, cur_jobs: 5, actual childs: 3
...
If the sleep is changed to be random, it might work correctly for the whole 30
iterations, which points to a race condition somewhere?
- Cris
Re: nameref bug?
On 9/3/14, 1:14 PM, lolilolicon wrote: > Yes, they're convenient, and make the code look somewhat more > readable, compared to equivalent `eval` or `printf -v` statements. > Functionally, they're all the same. > And they all suffer from the same issue. No matter which of those > three is used, one has to be very careful not to create name > collisions which can result in non-obvious bugs, sometimes deep in the > function call stack. One will have to invent his own variable naming > conventions to avoid such bugs; for instance, I have written a > reminder for my own script, > https://github.com/lolilolicon/FFcast/blob/master/HACKING.markdown I think that is a consequence of mixing bash's dynamic scoping with the ksh93-derived nameref feature. It's simpler in ksh93, which uses static scoping. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: nameref bug?
On Wed, Sep 3, 2014 at 9:09 PM, Chet Ramey wrote: >> There isn't much written on namerefs for two reasons: >> >> 1) They're quite new. >> 2) They're pretty useless. :( > > It depends on what your expectations are. Namerefs are essentially variable > name aliases. For their stated purpose -- passing variable names to shell > functions and allowing those functions to modify the named variable -- they > are ok. Yes, they're convenient, and make the code look somewhat more readable, compared to equivalent `eval` or `printf -v` statements. Functionally, they're all the same. And they all suffer from the same issue. No matter which of those three is used, one has to be very careful not to create name collisions which can result in non-obvious bugs, sometimes deep in the function call stack. One will have to invent his own variable naming conventions to avoid such bugs; for instance, I have written a reminder for my own script, https://github.com/lolilolicon/FFcast/blob/master/HACKING.markdown
Re: SEGFAULT if bash script make "source" for itself
On 8/28/14, 2:02 PM, bogun.dmit...@gmail.com wrote: > IMHO any user action should not lead to SIGSEGV! I am not objecting against > recursive "sourse" itself. But when I got SIGSEGV from "bash", I have no > idea why this is happened. I have made recursive "sourse" by mistake and > spend a lot of time looking up what exactly lead to SIGSEGV. > > Put a configurable limit on the deep of recursive source. There is almost > no variant for legal usage of recursive source on deep... 1 for > example. If someone need such recursion deep, he alway can raise limit or > turn it off by setting it to 0. This is more or less the way I am leaning. In the next version of bash, it will be possible to set a limit on the number of recursive source/. or eval calls at compile time. This will be accomplished by changing a define in config-top.h. There will be no limit enabled by default. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: nameref bug?
> There isn't much written on namerefs for two reasons: > > 1) They're quite new. > 2) They're pretty useless. :( It depends on what your expectations are. Namerefs are essentially variable name aliases. For their stated purpose -- passing variable names to shell functions and allowing those functions to modify the named variable -- they are ok. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
