From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23410 invoked by alias); 25 Aug 2013 22:01: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: 31666 Received: (qmail 19690 invoked from network); 25 Aug 2013 22:01:29 -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: <130825150104.ZM15563@torch.brasslantern.com> Date: Sun, 25 Aug 2013 15:01:04 -0700 In-reply-to: <20130825195946.2f9799c6@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: zpty non-functional?" (Aug 25, 7:59pm) References: <20130824124422.GA14766@mugenguild.com> <130824131041.ZM15573@torch.brasslantern.com> <20130824224839.5830e7fd@pws-pc.ntlworld.com> <130824170157.ZM15713@torch.brasslantern.com> <20130825195946.2f9799c6@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: zpty non-functional? MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Aug 25, 7:59pm, Peter Stephenson wrote: } } I added a test, but if instead of using the pipe I add a string as } arguments to zpty -w it usually fails: I get some of the string } followed by the whole of the string in the output. This suggests the } write is doing something weird. I modified the test to use "zpty cat 'strace cat 2>file'" and to use "zpty -w cat sample strings" instead of the pipe, then examined the strace output. The "cat" process always reads/writes exactly what it is meant to, even when the test fails. I then suspected that the problem is with "ztpy -r" not with -w. If I change the test to write two lines: print a line of text | zpty -w cat var=; zpty -r cat var zpty -w cat sample strings var=; zpty -r cat var then it always succeeds. If I swap the order so that the pipe is the second of the two writes, then it always *fails*, repeating the same output ("sample strings") twice, but strace still shows cat reading and writing the correct two lines in the correct order. Further testing by using "cat > /dev/null" shows that when "zpty -w" is used, the pty acts as if it is in echo mode, so "zpty -r" reads back what zpty -w wrote. In the pipe mode, for some reason, this does not happen. ptywrite() is called just once in either case, and I confirmed that ptysettyinfo() is being called at pty setup. If I put in some debugging statements such as zwarn calls in ptywrite, then I sometimes get only partial echo behavior, e.g., I'll get back "samplesample strings" and then "a line of text". I also tried adding a pid > 0 branch to the zfork conditional in which close(slave) is done [which seems like the right thing anyway] but that did not fix the behavior, although I thought briefly that it changed it. Finally I tried putting a "sleep 1" in the test before the first write to the pty. This makes it succeed 100% of the time, regardless of the order of the pipe or direct write. This leads me to conclude that it's a race condition: The master writer may read back what it wrote, up until the point that there is a process on the slave side consuming it instead. Whether this means we want to copy the synch[] pipe hack from exec.c to prevent zpty from returning before the child process is running, or just document the possible race, I will leave up to consensus (or PWS).