From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15235 invoked by alias); 25 Oct 2013 15:13:31 -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: 31896 Received: (qmail 703 invoked from network); 25 Oct 2013 15:13:26 -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: <131025081311.ZM9080@torch.brasslantern.com> Date: Fri, 25 Oct 2013 08:13:11 -0700 In-reply-to: <20131025110056.1757a5ab@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Shell job structure" (Oct 25, 11:00am) 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> <131024220214.ZM8256@torch.brasslantern.com> <20131025110056.1757a5ab@pwslap01u.europe.root.pri> 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 On Oct 25, 11:00am, Peter Stephenson wrote: } Subject: Re: Shell job structure } } On Thu, 24 Oct 2013 22:02:14 -0700 } Bart Schaefer wrote: } > } 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. } } There's a wider problem of what happens inside nested control } structures, in particular functions. Consider what happens when you use } "pipestatus" inside a function, and then try to apply it to a pipeline, } that happens to run that function at the right hand end, after the whole } pipeline has finished. You mean like this? % true | false | true | (){ false | true | false; print $pipestatus }; print $pipestatus 1 0 1 0 1 0 0 Here's a loop construct: % false | true | false | while true | false | true; do print $pipestatus; break; done; print $pipestatus 0 1 0 1 0 1 0 If that's not what you mean, then I'm not sure what is expected here. } Logically, at least, this requires some kind of } hierarchical handling of jobs, not processes --- although simply saving } and restoring the current job might be good enough. Does the current } system take account of this kind of thing properly? After 31879+31885, pipestats isn't assigned until the Job object is deleted (which only happens after all parts of the job are finished) *except* in one case: the job was suspended. I'm pretty sure there is still a race condition in that circumstance wherein the parent shell may decide the current-shell task is done because a component process hasn't yet received the signal. Anyway, the point is that if the outer pipeline doesn't assign pipestats until the current-shell construct at the tail has completed, then it's theoretically safe to use $pipstatus for pipelines inside that construct. } If so, maybe things are better than I thought. One thing I still don't understand about this is the exactly when the STAT_SUPERJOB flag is applied and whether that's going to affect some case that we haven't yet thought to test. There's a huge comment in exec.c that attempts to explain it, but ... There's a complication in that exec.c also says -- /* If this job has finished, we leave it as a * normal (non-super-) job. */ -- which I'm afraid might complicate the handling of pipestats in a way we're not expecting. This is all probably related to the race condition that I just mentioned, and indeed the big comment ends with: * The code for all this is distributed over three files (exec.c, jobs.c, * and signals.c) and none of them is a simple one. So, all in all, there * may still be bugs, but considering the complexity (with race conditions, * signal handling, and all that), this should probably be expected.