Am 05.05.2012 06:28, schrieb Mike Frysinger: > On Friday 04 May 2012 16:17:02 Chet Ramey wrote: >> On 5/4/12 2:53 PM, Mike Frysinger wrote: >>> it might be a little racy (wrt checking cnt >= 10 and then doing a wait), >>> but this is good enough for some things. it does lose visibility into >>> which pids are live vs reaped, and their exit status, but i more often >>> don't care about that ... >> What version of bash did you test this on? Bash-4.0 is a little different >> in how it treats the SIGCHLD trap. > bash-4.2_p28. wait returns 145 (which is SIGCHLD). > >> Would it be useful for bash to set a shell variable to the PID of the just- >> reaped process that caused the SIGCHLD trap? That way you could keep an >> array of PIDs and, if you wanted, use that variable to keep track of live >> and dead children. > we've got associative arrays now ... we could have one which contains all the > relevant info: > declare -A BASH_CHILD_STATUS=( > ["pid"]=1234 > ["status"]=1 # WEXITSTATUS() > ["signal"]=13 # WTERMSIG() > ) > makes it easy to add any other fields people might care about ... > -mike Is there actually a guarantee that there will be 1 SIGCHLD for every exited process. Isn't it actually a race condition? what happens if 2 subprocesses exit simultaneously. or if a process exits while already in the SIGCHLD trap. I mean my normal interpretation of a interrupt/event/trap is just a notification that I need to check what has happened. Or that there was an event not the extent of the event? I keep feeling that the following is bad practice
trap ': $(( --cnt ))' SIGCHLD and would be better something like this trap 'cnt=$(jobs -p | wc -w)' SIGCHLD as such you would need something more like. declare -a BASH_CHILD_STATUS=([1234]=1 [1235]=1 [1236]=1) declare -a BASH_CHILD_STATUS_SIGNAL=([1234]=13 [1235]=13 [1236]=13)
