From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13623 invoked by alias); 16 Sep 2016 22:24:58 -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: 39368 Received: (qmail 18268 invoked from network); 16 Sep 2016 22:24:58 -0000 X-Qmail-Scanner-Diagnostics: from mail-pf0-f177.google.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(209.85.192.177):SA:0(0.0/5.0):. Processed in 0.153299 secs); 16 Sep 2016 22:24:58 -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=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=XxdVW8gRzqhZmLx0sQifYxOpuomFmvGu8KWx5qmvIdA=; b=ItmC2PASj0Cv79GsIo7EOBtHJaK6YMPnw6/I78O92CfUIvf2+sMGe6B/+9eCVNLbQX jPBypvcawCex7TDXkL8R3T+cv5NqmZMt4KOexpvbZQP0nprDSL747uD8USa2hGw8si/n wsQeEDBUQFDwPjPSWgvCjADpmHjTqeP4XCpTcpKURsCNwsyQ0qPdcpOtjkjaKxrlMFfO Grgo+2XRARoZZMfH9fCNJVHYxlxWBLXDlmpAlZLp07olOfIdIYjlWwLhaoji6y2u4/DK uMehK97DvTtdTioUvxrz9e5IX0T7vQQittjNYoN7WhhNChwIqSx3csjp99mwjKTUIJKd eN4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=XxdVW8gRzqhZmLx0sQifYxOpuomFmvGu8KWx5qmvIdA=; b=jgwfQMkIHrq4TZjiw36XZw5K3bNZEpSiPsRGhvM/bcyHTxZysiJJXIMX4Mt2UvPjNw cFE8xsNQN1L2G0aCad1y6sg/pV/dEE2meMghruYMJiSlVMadqb5FGTji9klde5F/926Q /Ghxpw3/FSQcV78bURwlrQeXlGe3ag3KzYFNPd+lR35ERaGx7FSoUi5cvNDk6ZkZa1ii 9Vmyve7wZmUBZRlm4gkSvI6qfvl71et3dcqSQhjWw22CW8ugRGGm+jG4jcGSFAc6CsUl esfgnNby8+Ild/XeMBhALH5KaxkGkzN3K8pqjYWXWu1rYQfw6dA2CVNyD6IPe7Kv6Wu7 rxdg== X-Gm-Message-State: AE9vXwPqgH8LBoGyWf+gooXF6pnSY8T1f6N7lmZUYaAJFC7BXEqthikvJTMUx+ZsIp63uw== X-Received: by 10.98.93.85 with SMTP id r82mr12680641pfb.168.1474064691493; Fri, 16 Sep 2016 15:24:51 -0700 (PDT) From: Bart Schaefer Message-Id: <160916152507.ZM26599@torch.brasslantern.com> Date: Fri, 16 Sep 2016 15:25:07 -0700 In-Reply-To: <20160916215241.0b1531d7@ntlworld.com> Comments: In reply to Peter Stephenson "Re: Another bug when suspending pipelines" (Sep 16, 9:52pm) References: <20160916133302.1f447ca0@pwslap01u.europe.root.pri> <160916113801.ZM11473@torch.brasslantern.com> <20160916215241.0b1531d7@ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Another bug when suspending pipelines MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 16, 9:52pm, Peter Stephenson wrote: } Subject: Re: Another bug when suspending pipelines } } On Fri, 16 Sep 2016 11:38:01 -0700 } Bart Schaefer wrote: } > 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. Hm. That means that if you *backgound* the "sleep" and bother looking with "ps", you will see a process that is in T state while the shell claims it is running. I suppose that's worked fine for the last lo these many years, but does it not mean that an external "kill -CONT" can cause the expected order of events to be violated? } > * 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. Maybe it shouldn't. Ugh.