This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin passes through null writes to other software when redirecting standard input/output (i.e. piping)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]