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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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