delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
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 |
Message-ID: | <4F9B38FB.9030607@dancol.org> |
Date: | Fri, 27 Apr 2012 17:25:31 -0700 |
From: | Daniel Colascione <dancol AT dancol DOT org> |
User-Agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 |
MIME-Version: | 1.0 |
To: | cygwin AT cygwin DOT 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 DOT GO25385 AT calimero DOT vinschen DOT de> <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> |
In-Reply-To: | <025501cd24c6$6a353990$3e9facb0$@motionview3d.com> |
X-IsSubscribed: | yes |
Mailing-List: | contact cygwin-help AT cygwin DOT com; run by ezmlm |
List-Id: | <cygwin.cygwin.com> |
List-Subscribe: | <mailto:cygwin-subscribe AT cygwin DOT com> |
List-Archive: | <http://sourceware.org/ml/cygwin/> |
List-Post: | <mailto:cygwin AT cygwin DOT com> |
List-Help: | <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs> |
Sender: | cygwin-owner AT cygwin DOT com |
Mail-Followup-To: | cygwin AT cygwin DOT com |
Delivered-To: | mailing list cygwin AT cygwin DOT com |
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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |