From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28724 invoked by alias); 1 May 2018 09:30:13 -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: 42742 Received: (qmail 28245 invoked by uid 1010); 1 May 2018 09:30:13 -0000 X-Qmail-Scanner-Diagnostics: from mailout2.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.12):SA:0(-6.9/5.0):. Processed in 2.311163 secs); 01 May 2018 09:30:13 -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, 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 mailout2.w1.samsung.com 20180501092340euoutp023caee84139064e9fa0a3effa2c003f83~qevXe9VeS2048020480euoutp02T DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1525166620; bh=wP3NJtbNQU30yZNf89ZjIV3RcXCL5B3IpCQRSMFw0k8=; h=Date:From:To:Subject:In-Reply-To:References:From; b=UxsQj/0NKzE0HgY0jRcpkmGMXDO5haNSzhS4fpocUCuM810+FWzGK3MJHKyYkbLol iT5hdivJMSrpHznmE37yh6adQ52faM9j6/zkoAxH63F4B/JyzIX2i0DhJGtFWXHgdx S5uoWFsY06RWlR6C7wOl3dTSnxi/kNYBzDBsUmkc= X-AuditID: cbfec7f4-6f9ff700000043e4-91-5ae8321b1c83 Date: Tue, 1 May 2018 10:23:33 +0100 From: Peter Stephenson To: Subject: Re: Forking earlier for background code Message-ID: <20180501102333.74fb7581@camnpupstephen.cam.scsc.local> In-Reply-To: <20180423092900.504865dd@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-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsWy7djPc7rSRi+iDJ53slscbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujKVTPrEVnOWvWPT5A2MD40KeLkZODgkBE4mlfbvYuxi5OIQE VjBK7Du6EcrpY5JovNHADOH0Mkn82vSJGaala/FpqMRyRontjx6zwVVN+tDLCuGcZpQ4/baP BaRFSOA8o8Ss34EgNouAisSkpxvB4mwChhJTN81mBLFFBCQlrjWfBrOFBQwk3k7fCLaOV8BZ 4umpe2BxTgEXif3Lu4C2cXDwCwhJXGi2hbjIXuLonpNMEOWCEidnPgEbzywgL7H97RywSyUE 3rNJ9K+G6JUAmvO93QSiV1ji1fEt7BC2jMT/nfOZIOqbGSXW3r/PBpHoAbp/cSiEbS3Rd/si I8gcZgFNifW79CFG2kpc3G0DYfJJ3HgrCHEBn8SkbdOZIcK8Eh1tQhAz1CR2NG1lnMCoMgvJ zbOQ3DwLYfwCRuZVjOKppcW56anFRnmp5XrFibnFpXnpesn5uZsYgWng9L/jX3Yw7vqTdIhR gINRiYeXQ/55lBBrYllxZe4hRgkOZiUR3pUdz6KEeFMSK6tSi/Lji0pzUosPMUpzsCiJ88Zp 1EUJCaQnlqRmp6YWpBbBZJk4OKUaGFfMaPP/ekjp3q4Fk84e0LGqsGxeUaW/eHZIQuW8WU4L thVtE2+/X8McnLjOOzx0lfN/a556C72oB1pbbfhOrHzSdXJ1y5yv1qLmH57zfHEMlEr5UbTd T68xJ+jEmxxzuS/nppj9Ur/qecmbcelymUTPw+8X718o1P+yfNrqRL+OO+u/e9T+nafEUpyR aKjFXFScCAACshtJ/wIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjkeLIzCtJLcpLzFFi42I5/e/4XV0poxdRBjMv8FscbH7I5MDoserg B6YAxig9m6L80pJUhYz84hJbpWhDCyM9Q0sLPSMTSz1DY/NYKyNTJX07m5TUnMyy1CJ9uwS9 jKVTPrEVnOWvWPT5A2MD40KeLkZODgkBE4muxaeZuxi5OIQEljJKnLt/lhEiISPx6cpHdghb WOLPtS42iKJuJok9f1ezQjinGSUWTdnCAuGcZ5Q4cPImG0gLi4CKxKSnG1lAbDYBQ4mpm2aD jRURkJS41nwazBYWMJB4O30jM4jNK+As8fTUPbA4p4CLxP7lMOuesUtc/T4LKMHBwS8gJHGh 2RbiJHuJo3tOMkH0CkqcnPkEbBezgI7EiVXHmCFseYntb+cwT2AUnoWkbBaSsllIyhYwMq9i FEktLc5Nzy020itOzC0uzUvXS87P3cQIjIttx35u2cHY9S74EKMAB6MSDy+H/PMoIdbEsuLK 3EOMEhzMSiK8KzueRQnxpiRWVqUW5ccXleakFh9iNAUGxkRmKdHkfGDM5pXEG5oamltYGpob mxubWSiJ8543qIwSEkhPLEnNTk0tSC2C6WPi4JRqYJw/c1PVGd6FK8Qq0pZc9HJlUksO1mSK fHDZOD3l046F62KybnxhWbdB9l/5tzteTesnCJ888e9vW3LQ0alPZnrHsBw0EGHuf7vdJWET B/McHc7tCne6bN+/aXGfXTljtkunUrpNqkqd4sJ2oeeN1lPt3aW7re03miz65vybbWqqgXam kODWzUosxRmJhlrMRcWJADZ+lyWhAgAA X-CMS-MailID: 20180501092338eucas1p1380c15b09e42cf6e69b0536e4a5e6508 X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-MTR: 20180501092338eucas1p1380c15b09e42cf6e69b0536e4a5e6508 X-EPHeader: CA CMS-TYPE: 201P X-CMS-RootMailID: 20180324221021epcas1p184507a6328dbd505b97db69c1f9d8194 X-RootMTR: 20180324221021epcas1p184507a6328dbd505b97db69c1f9d8194 References: <180323221959.ZM27569@torch.brasslantern.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> <20180423092900.504865dd@camnpupstephen.cam.scsc.local> I haven't seen any problems with the changes in the list below over the last week so I'm going to squash the changes and push the result. pws On Mon, 23 Apr 2018 09:29:00 +0100 Peter Stephenson wrote: > - 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).