From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8615 invoked by alias); 23 Apr 2018 08:29:12 -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: List-Unsubscribe: X-Seq: 42702 Received: (qmail 8347 invoked by uid 1010); 23 Apr 2018 08:29:12 -0000 X-Qmail-Scanner-Diagnostics: from mailout1.w1.samsung.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(210.118.77.11):SA:0(-6.9/5.0):. Processed in 1.781738 secs); 23 Apr 2018 08:29:12 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,T_DKIMWL_WL_HIGH,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: p.stephenson@samsung.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20180423082904euoutp01b07d7db96bbb0c0744c1dc20c729b3ef~oA1al0zPQ1389513895euoutp01J DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1524472144; bh=6iJOxP49DVLXsiRu7/TZtbfSqT5dyzw2mlx/9YxV/t4=; h=Date:From:To:Subject:In-reply-to:References:From; b=vEGC7o1U0P8LcIGI6hEFTOmeht6teFwJ3Ky16D+iuA/0ooCzDgCF1tENrnZ3Ib+Sl ePk/ZN7SsvCx9Qj9n6w5LYaxxGBzwkUoneI444ZytA5OQDzUl8AjSwb2UFz5fAIhSw +tJyT/sW/fL32bAVbgKl7GPIj/bf0s2c4RAI+eU8= X-AuditID: cbfec7f2-1dbff70000011644-82-5add994f0e55 Date: Mon, 23 Apr 2018 09:29:00 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: Forking earlier for background code Message-id: <20180423092900.504865dd@camnpupstephen.cam.scsc.local> In-reply-to: <20180420102839.073d539b@camnpupstephen.cam.scsc.local> Organization: SCSC X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsWy7djPc7r+M+9GGXTM4LY42PyQyYHRY9XB D0wBjFFcNimpOZllqUX6dglcGbeWzWMvWCRUsWTmFaYGxr18XYycHBICJhINpzaxdjFycQgJ rGCUONQ5kw3C6WWSaNz3lxWmanPTbCaIxDJGiZ+TjrFAONOYJFauOgLVf4ZRYte+qcwQzgVG ifaXj9hA+lkEVCXeLdjICGKzCRhKTN00G8wWERCXOLv2PAuILSxgIPF2+kZmEJtXwFmis+kQ WA2ngIvEpZsgNgcHv4CQxIVmW4iT7CWO7jnJBFEuKPFj8j2wMcwCOhLbtj1mh7DlJTaveQt2 j4TAFDaJnVO2MUE0u0hsvXkU6jdhiVfHt7BD2DISnR0HmSAamhkl1t6/zwaR6GGUmLU4FMK2 lui7fZERYgOfxKRt05lBjpMQ4JXoaBOCKPGQuHbpM9RMR4lVe9ugIXSLXeJwYw/TBEb5WUgO n4Xk8FlIDl/AyLyKUTy1tDg3PbXYMC+1XK84Mbe4NC9dLzk/dxMjMPZP/zv+aQfj10tJhxgF OBiVeHh36N6NEmJNLCuuzD3EKMHBrCTCW+wHFOJNSaysSi3Kjy8qzUktPsQozcGiJM4bp1EX JSSQnliSmp2aWpBaBJNl4uCUamCcOC3g6QPdabsmzF6zcufezT9Oi2qtbj8z5Sjv3UlV/bbL tQSFot71bZDaoOn9gFvy17bV59PY9s/Ts3xyRixar0bkjNv7UJUg1ecPufTvTbnAb855QmR3 wcQjPhFyvScvn3grNO/e1H19YXGsPlNllTYZK/X+CezpTtuqy3/xJuNKy32rMxd8UGIpzkg0 1GIuKk4EAGoQQJ/5AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsVy+t/xy7p+M+9GGax/pWlxsPkhkwOjx6qD H5gCGKO4bFJSczLLUov07RK4Mm4tm8desEioYsnMK0wNjHv5uhg5OSQETCQ2N81m6mLk4hAS WMIosXDuNBYIZwaTxOxTqxkhnHOMEj3Te1khnAuMEhe2fmID6WcRUJV4t2AjI4jNJmAoMXXT bDBbREBc4uza8ywgtrCAgcTb6RuZQWxeAWeJzqZDYDWcAi4Sl24egtpwi13iy5NVQEM5OPgF hCQuNNtC3GcvcXTPSSaIXkGJH5Pvgc1kFtCS2LytiRXClpfYvOYt2HwhAXWJG3d3s09gFJqF pGUWkpZZSFoWMDKvYhRJLS3OTc8tNtQrTswtLs1L10vOz93ECAzbbcd+bt7BeGlj8CFGAQ5G JR7eHbp3o4RYE8uKK3MPMUpwMCuJ8Bb7AYV4UxIrq1KL8uOLSnNSiw8xSnOwKInznjeojBIS SE8sSc1OTS1ILYLJMnFwSjUwpk3+UbJt3nMlJrvAcFeXZ8suX9vG5mXeI7jmzc/NC1Q4ds6Z OZFrT7pkxDHN1SKFxrumbRNhvrunZu7n/lsb/2/OCbhzzNRdakNvPLf9cwn5tXM1VQUz5yrE GVjm8T++GdTBusHsf9lPtu7Kbd1dJaftd7mIfFGdYivldU5RSm5WyTxTwQcTlViKMxINtZiL ihMB6qlUHVcCAAA= X-CMS-MailID: 20180423082902eucas1p2b29dfed5fe295af3bd6694dcad167130 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180324221021epcas1p184507a6328dbd505b97db69c1f9d8194 X-RootMTR: 20180324221021epcas1p184507a6328dbd505b97db69c1f9d8194 References: <180323221959.ZM27569@torch.brasslantern.com> <20180324080514.txxyrb3qiztu4pqt@gmail.com> <180324150945.ZM32251@torch.brasslantern.com> <20180410124545.13fccd5d@camnpupstephen.cam.scsc.local> <20180410145926.64c4f671@camnpupstephen.cam.scsc.local> <180411151025.ZM19332@torch.brasslantern.com> <20180412172342.52df6b10@camnpupstephen.cam.scsc.local> <20180415162326.GA12549@chaz.gmail.com> <20180415185804.GB12549@chaz.gmail.com> <180416223910.ZM32002@torch.brasslantern.com> <20180417101947.5fd347df@camnpupstephen.cam.scsc.local> <180417090926.ZM2456@torch.brasslantern.com> <20180417173558.769503bd@camnpupstephen.cam.scsc.local> <180417105243.ZM2929@torch.brasslantern.com> <20180419104039.7b86ed2b@camnpupstephen.cam.scsc.local> <20180420102839.073d539b@camnpupstephen.cam.scsc.local> On Fri, 20 Apr 2018 10:28:39 +0100 Peter Stephenson wrote: > It may well be possible to expand the logic to track down other cases > where we know we can know we're going to need to fork, so can do so > early to get fewer side effects (and slightly optimise the main > shell). I've been working on this, and as it's kind of interesting I think I'm going to push my additional work on a branch called fork_early. The commit log entries are fairly descriptive, but here's a summary of what I've done. - Move the early fork even earlier --- the code immediately above it was to do with initial examination of command line arguments, and the new fork code deals exactly with the cases where we don't need to know this. - _exit if we forked and were going to return early from execcmd_exec(). This shows up particularly in one case with the preceding change --- namely assignments. - As suggested, remove the previous code in the caller that did the fork there if we recognised early this was code to run within the shell but in an early part of the pipeline. This is now redundant. (I'm wondering if this special code was there so that things like "foo=bar &", which would have polluted the main shell, didn't push the original problem beyond the pain barrier --- i.e. it was always just a partial workaround.) - That change revealed two other things that needed doing. First, set "last1" when we do the early fork so that subsequent code in the forked shell knows we are going to exit. This was revealed by the failure of a test that sets an EXIT trap in the left hand side of a pipeline. (Existing exit traps are cleared here, but it's possible to set a new one and it should go off when the forked shell exits.) - Second, Bart's woraround in zsh-wrokers/32171 for a leaked fd needed rewriting. The change is to ensure we always close the pipe fd that's not needed in the forked code when we fork (i.e. the input side of the pipe on the LHS --- the output side on the RHS was simpler and always managed OK). This seems reasonably transparent so I hope it's not going to lead us down a blind alley (Bart added an explicit test for the case that was failing). We could probably do with some tests, although testing with background code is a pain. pws