From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24482 invoked by alias); 28 Apr 2012 00:25:51 -0000 Received: (qmail 24461 invoked by uid 22791); 28 Apr 2012 00:25:49 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=BAYES_00,KHOP_THREADED,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from dancol.org (HELO dancol.org) (96.126.100.184) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 28 Apr 2012 00:25:36 +0000 Received: from c-76-22-66-162.hsd1.wa.comcast.net ([76.22.66.162] helo=[0.0.0.0]) by dancol.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1SNvTk-0007k3-8n for cygwin@cygwin.com; Fri, 27 Apr 2012 17:25:36 -0700 Message-ID: <4F9B38FB.9030607@dancol.org> Date: Sat, 28 Apr 2012 00:25:00 -0000 From: Daniel Colascione User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping) References: <020501cd23f2$20f07620$62d16260$@motionview3d.com> <20120427143753.GO25385@calimero.vinschen.de> <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> In-Reply-To: <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-04/txt/msg00658.txt.bz2 On 4/27/2012 3:38 PM, James Johnston wrote: > So I think for sure, Cygwin's use of message pipes is breaking a lot > of Windows software, because of the null writes. And ALSO additionally > perhaps because of this: while reading MSDN today, I came across an > interesting snippet that probably indicates a second source of problems > I have not explicitly tested for, but would probably find: > > "If the specified number of bytes to read is less than the size of > the > next message, the function reads as much of the message as possible > before returning zero (the GetLastError function returns > ERROR_MORE_DATA). The remainder of the message can be read using another > read operation." Confusingly, a PIPE_TYPE_MESSAGE pipe's read end can be in either PIPE_READMODE_MESSAGE or PIPE_READMODE_BYTE mode. You're describing the behavior of PIPE_READMODE_MESSAGE; Cygwin's pipes are in PIPE_READMODE_BYTE, so they don't have this particular problem --- although the null-write problem remains. > 1. Why on earth did Cygwin start using message pipes? "adopted to > fix > a problem" doesn't help... Googling site:Cygwin.com "message pipe" - > didn't yield anything either. I do know older Cygwin versions worked > fine, and I had no problem with piping data to/from both Cygwin and > non-Cygwin programs. I am sure it was changed for a good reason, but > would someone be willing to offer an explanation for why message pipes > are now used? Do they have problems reading from a byte pipe? Writing to > a byte pipe? Both? Under what conditions? IIRC, it had something to do with preserving message boundaries at the TTY later. Again IIRC (and I only faintly recall this part) the PTY layer has to deliver one line at a time to readers. If a client calls read(2) with a giant buffer, he's still supposed to get back only a single line at a time. A message-mode pipe seems like a good way to provide these semantics because it preserves write boundaries --- so if you write only a line at a time, the reader reads only a line at a time. It's a shame that this approach causes problems. Why can't only pseudoterminal pipes be created as PIPE_TYPE_MESSAGE? Cygwin already has special logic to tell whether a handle it's opening is a pty and to treat it specially in that case. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple