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

[Mike Frysinger]

On Sunday 06 May 2012 03:25:27 John Kearney wrote:
> Am 06.05.2012 08:28, schrieb 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.
> 
> but I think my point still stands
> trap ': $(( cnt-- ))' SIGCHLD
> is a bad idea, you actually need to verify how many jobs are running not
> just arbitrarily decrement a counter, because your not guaranteed a trap
> for each process. I mean sure it will normally work, but its not
> guaranteed to work.

if `wait` setup BASH_CHILD_STATUS, then you wouldn't need the SIGCHLD trap at 
all.  you could just do `wait`, get the info from BASH_CHILD_STATUS as to what 
child exactly was just reaped, and then proceed.

as to the underlying question, since it's possible for bash itself to receive 
stacked SIGCHLDs, there's no reason it wouldn't be able to execute the trap 
the right number of times.
-mike

signature.asc
Description: This is a digitally signed message part.