From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2698 invoked by alias); 16 Sep 2016 20:58:19 -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: 39366 Received: (qmail 6063 invoked from network); 16 Sep 2016 20:58:19 -0000 X-Qmail-Scanner-Diagnostics: from know-smtprelay-omc-5.server.virginmedia.net 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(80.0.253.69):SA:0(-0.0/5.0):. Processed in 0.847764 secs); 16 Sep 2016 20:58:19 -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=-0.0 required=5.0 tests=SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: p.w.stephenson@ntlworld.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _smtprelay.virginmedia.com designates 80.0.253.69 as permitted sender) X-Originating-IP: [86.21.161.213] X-Spam: 0 X-Authority: v=2.1 cv=HZrpNXw8 c=1 sm=1 tr=0 a=oo3MgO7t/4XyXFuSzI3dDQ==:117 a=oo3MgO7t/4XyXFuSzI3dDQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=q2GGsy2AAAAA:8 a=faATXxNulEKo4EnMbZYA:9 a=CjuIK1q_8ugA:10 a=z9dJwno5l634igLiVhy-:22 Date: Fri, 16 Sep 2016 21:52:41 +0100 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: Another bug when suspending pipelines Message-ID: <20160916215241.0b1531d7@ntlworld.com> In-Reply-To: <160916113801.ZM11473@torch.brasslantern.com> References: <20160916133302.1f447ca0@pwslap01u.europe.root.pri> <160916113801.ZM11473@torch.brasslantern.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.28; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 16 Sep 2016 11:38:01 -0700 Bart Schaefer wrote: > * The parent responds by stopping all the other jobs in the current > pipeline. It forks the brace expression into a new process and > stops that one as well (or maybe that one stops itself, I don't > recall the exact sequence of events here). This is where the problem was. The forked shell is supposed to stop itself, but because it was in the same process group it was also being stopped by the parent shell. > The parent has to manage all three of these jobs, because it can't > hand off the already-forked "sleep 7" to the newly-forked brace job. > It has to arrange that the brace job can be sent a SIGCONT on "fg" > but not actually do anything until the "sleep 7" has finished; I > believe that's handled by the "synch" pipes and hidden reads; in any > case, it works. The parent shell "simply" waits for the non-shell processes that were forked directly from the parent shell on the right of the pipeline and restarts the forked shell to run the rest (which may, of course, include other external processes) when those have finished. The synch just ensures syncronisation at the start, though I'm not sure what good it's doing. > On "fg" the parent: > * makes "sleep 7" the tty group leader again > * sends SIGCONT everywhere except the forked subshell > * and waits for "sleep 7" to exit. ? > If I'm correct about the synch pipe, the tail of the brace expression > is blocked waiting to read that. No, it's stopped itself waiting to be resstarted. > * makes the tail of the brace expression into a process group which > becomes the tty leader, and > * writes a byte on the synch pipe to wake it up. This all happened in one go when the shell was forked. (Its process group is the subject matter here.) pws