Re: Parallelism a la make -j <n> / GNU parallel

[Mike Frysinger]

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.