From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2610 invoked by alias); 25 Oct 2013 05:02:21 -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: 31894 Received: (qmail 20342 invoked from network); 25 Oct 2013 05:02:16 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <131024220214.ZM8256@torch.brasslantern.com> Date: Thu, 24 Oct 2013 22:02:14 -0700 In-reply-to: <20131008214437.41dc396a@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Shell job structure" (Oct 8, 9:44pm) References: <20131005223159.25fea6a0@pws-pc.ntlworld.com> <131006173621.ZM31831@torch.brasslantern.com> <20131007102529.5354f342@pwslap01u.europe.root.pri> <131007074049.ZM32707@torch.brasslantern.com> <20131008214437.41dc396a@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Shell job structure MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Just to tie this off, as we now have this mostly addressed: On Oct 8, 9:44pm, Peter Stephenson wrote: } Subject: Shell job structure } } On Mon, 07 Oct 2013 07:40:49 -0700 } Bart Schaefer wrote: } > - because external jobs can exit and be reaped in arbitrary order, even } > in a pipeline, the job table is used to keep track of which position } > in the array to update More specifically: The "procs" linked list in a job table entry keeps track of the array positions. The complication is .. } > - jobs that run in the current shell don't have a complete job table entry ... and the "incomplete" part is that there *is* a job table entry, but the current shell task doesn't have an entry in the "procs" list. } > [cf. all the gyrations to suspend/background a loop] and aren't "reaped" } > in the same code path as external jobs, so the wrong array position (or } > none at all) may get updated Because zsh "forks to the left" to keep the tail of the pipeline in the current shell, the status of the current shell task has to be added to the end of $pipestatus (internally "pipestats"), which means an accurate count of the number of other processes in the pipeline is essential. } > - the incorrect update depends on whether the external job exited AND got } > reaped before the current-shell job has completed, because of the way } > reaping updates the job table, so correctness is unpredictable This has been fixed by moving the update of pipestats to the point where the job table entry is deleted, instead of trying to do it at the point where individual processes have their status updated. } > - complex commands "in the current shell" may have external subjobs that } > need a separate pipestatus (this applies only at end of a pipeline) I believe this has also been worked around by the above, but one thing we haven't tested yet is what value $pipestatus has *inside* a loop. } The job table would become a list of top-level jobs, while the job } structure would have pointers to nested jobs. As I mentioned elsewhere, the procs list and "other" pointer into the job table serve this function. It still might be done more cleanly, but at least we avoided a full rewrite for now.