From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29254 invoked by alias); 7 Mar 2013 16:58:35 -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: 31126 Received: (qmail 21416 invoked from network); 7 Mar 2013 16:58:33 -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 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130307085830.ZM12345@torch.brasslantern.com> Date: Thu, 07 Mar 2013 08:58:30 -0800 In-reply-to: <20130306225341.GA12150@chaz.gmail.com> Comments: In reply to Stephane Chazelas "coproc fd leak leading to possible deadlock" (Mar 6, 10:53pm) References: <20130306225341.GA12150@chaz.gmail.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: coproc fd leak leading to possible deadlock MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Mar 6, 10:53pm, Stephane Chazelas wrote: : Subject: coproc fd leak leading to possible deadlock : : When we run an external command as a coproc, all is fine, but if : we run a subshell, that subshell ends up having open fds for : both ends of both pipes, leading to potential deadlocks Yes, I've been pointing out problems with coproc descriptor handling for a while now (search zsh-worker mailing list archives). So far I have not found any issues with zsh's descriptor handling that are not also shared by at least bash if not also ksh, so there hasn't been any effort put into fixing things for a while. : ~$ exec zsh -f : sc% coproc {sleep 100; sleep 100} The workaround for this one is to run a dummy coprocess *inside* the coprocess: % coproc { coproc : ; sleep 100; sleep 100 } This should force closed the descriptors in the subshell that were inherited from the parent shell, leaving the stdin/stdout connected to the original pipes. There's some discussion of why this happens (and why it's convoluted to detect the situation) in the archives. The short answer is that the descriptors are close-on-exec [which is why "coproc sh ..." works] but there's no exec with a subshell.