bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: Parallelism a la make -j <n> / GNU parallel
Date: Mon, 07 May 2012 09:00:33 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1

On 5/6/12 3:25 AM, 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.
>> -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.

It's certainly more robust to keep track of children that are running by
PID, but bash will run the SIGCHLD trap once for each child that exits.
(This doesn't work while using `wait' in Posix mode, since Posix requires
the trapped SIGCHLD to cause `wait' to return.)

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]