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

[John Kearney]

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.
> -mike
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.

Also I think the question would be is there any point in forcing bash to
issue 1 status at a time? It seems to make more sense to issue them in
bulk.
So bash could populate an array of all reaped processes in one trap
rather than having to execute multiple traps. This is what bash does
internally anyway?