From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22056 invoked by alias); 22 Oct 2014 18:38:53 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33509 Received: (qmail 5062 invoked from network); 22 Oct 2014 18:38:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_PASS autolearn=ham version=3.3.2 Message-ID: <5447F846.5050300@case.edu> Date: Wed, 22 Oct 2014 14:32:38 -0400 From: Chet Ramey Reply-To: chet.ramey@case.edu User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Bart Schaefer , zsh-workers@zsh.org CC: chet.ramey@case.edu Subject: Re: bug in zsh wait builtin - rhbz#1150541 References: <20141021210234.199eee3d@pws-pc.ntlworld.com> <141021235542.ZM14840@torch.brasslantern.com> In-Reply-To: <141021235542.ZM14840@torch.brasslantern.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Junkmail-Status: score=10/50, host=mpv6.cwru.edu X-Junkmail-Whitelist: YES (by domain whitelist at mpv1.tis.cwru.edu) On 10/22/14, 2:55 AM, Bart Schaefer wrote: > On Oct 21, 9:02pm, Peter Stephenson wrote: > } > } There's an explanatory note in the latest POSIX standard about this, > } quoted below. It seems that the shell is basically required to remember > } all background processes indefinitely (up to not very helpful get out > } clauses). As a baseline, CHILD_MAX here is 1024. This probably needs > } to be a special hash. > > Since you've bothered to look this up ... does it go on to say what the > shell is supposed to do if PIDs roll over so that a new background job > gets the same $! as some previous one? Is "kill" supposed to work the > same way? (Do we need to send an inquiry to austin-group? If so, you > will have to do it, my ability to post there has been messed up for a > long time.) The implicit assumption in the Posix spec is that the pid space is large: large enough that PIDs won't roll over and collide before you've gone through CHILD_MAX children. In practice, it happens surprisingly often. The way I do it is to add the PIDs of exited jobs to a list, and prune it if the list gets longer than the current child_max. I check after fork() and remove pids from the list if they recycle. `wait' knows how to look through this list for child PID statuses. -- ``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/