On Saturday 05 May 2012 23:25:26 John Kearney wrote: > 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 ... > > Is there actually a guarantee that there will be 1 SIGCHLD for every > exited process. > Isn't it actually a race condition?
when SIGCHLD is delivered doesn't matter. the child stays in a zombie state until the parent calls wait() on it and gets its status. so you can have `wait` return one child's status at a time. -mike
signature.asc
Description: This is a digitally signed message part.
