X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 q=dns; s=default; b=jQqfJVDFiXy3E/8o46HgRL/BBPw3q+nG3X1ZJIk2CfB
	JHFhGpe9qEAyoV5dYHmqGEWMa1BDAPd7x664UjsXHCag7MUVmfWB98J9rATNiH/f
	hiy1OeKtQsGeFObDjvsTPRW5FU5CUfEQRDYfV5tzuh/YnEVkE+N0udHbYMBd2KX0
	=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:to:references:in-reply-to:subject:date
	:message-id:mime-version:content-type:content-transfer-encoding;
	 s=default; bh=jDxK28muLTeq1dv9J1WgVTcXLZg=; b=pl+Dl0zChQCmn6Rzf
	wagCPOhxZjRgNQ27yqscLO6UeIVOlCsHZRkH+OWsR4Vb48s9ocn2uKK+JX0Kn2yL
	sw3rfkqTrgLbHyYnOu+SuGbD4sr64pSY9Xbrs/HfiAOS+ljzqGUMcwjEgixF/21P
	NuBI5KvN4+rD/4WMYUWpGMasy8=
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
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,BELOVED_BODY,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=no version=3.3.2
X-HELO: mout.perfora.net
From: "James Johnston" <JamesJ AT motionview3d DOT com>
To: <cygwin AT cygwin DOT com>
References: <02ee01cefdce$9c343300$d49c9900$@motionview3d.com> <5F8AAC04F9616747BC4CC0E803D5907D0C455040 AT MLBXv04 DOT nih DOT gov> <030c01cefff6$9c1fa3c0$d45eeb40$@motionview3d.com> <5F8AAC04F9616747BC4CC0E803D5907D0C457767 AT MLBXv04 DOT nih DOT gov>
In-Reply-To: <5F8AAC04F9616747BC4CC0E803D5907D0C457767@MLBXv04.nih.gov>
Subject: RE: Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
Date: Mon, 23 Dec 2013 19:31:10 -0000
Message-ID: <034901cf0015$89b57ec0$9d207c40$@motionview3d.com>
MIME-Version: 1.0
Content-Type: text/plain;	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

> > Check line 192 for a call to the WaitForAvailableConsoleInput function.
> 
> I guess they expect hFile to be a console handle (which IS waitable).
> 
> And my guess that they added the Peek intentionally to prevent the WaitFor
> call from slipping through (as we've seen it does, otherwise) on things
that
> weren't supposed to be there (such as pipes).
> They probably know of a side effect of peeking a pipe, which makes the
> WaitFor API block on them (thus, still create a good cancellation point
for the
> thread) -- again, as they would not expect a pipe there (but a good
console
> handle;  and if it isn't -- well, it's by design).
> 
> But I'm only speculating here.  On the other hand, I would not be
surprised to
> learn that one team in MS would not know how to deal with the pipes and
> introduced a bug, easily.  MS is a large company, and I witnessed such
things
> to happen in teams of a much smaller scale, from my own experience.

Perhaps, but how daft would you have to be to not realize that the handle
might be a pipe?  Did they never use any command line interface, like, ever?

I suspect the authors were aware it might be a pipe.  Immediately after
calling WaitForAvailableConsoleInput, they call ReadFile and check the
return value & error code.  They check for ERROR_BROKEN_PIPE, with a comment
"A pipe into stdin was closed.  Not an error, but EOF".  I think they
knew...  There are similar comments/checks when calling WriteFile to write
to stdout/stderr.

Although perhaps, as you might be alluding to, they did not realize that a
pipe isn't waitable (i.e. didn't RTFM).  At any rate, frustrating change.

> In our apps we use the Peek everywhere for pipe polling, and do not rely
on
> anything else.

Nice & convenient if you can do it.  Problem that Microsoft had was they
probably felt they had to have a solution that performs better than that if
it's going into a generic, widely-used framework...

> And from Cygwin point of view, I was trying to deal with mixing native
> Windows things and UNIX, and it seems to be a big no-no, from the entire
> design point -- Cygwin is not a tool for be-friending Windows and Unix,
rather
> a way to run your beloved GNU tools on a Windows box.

So it might seem.  I did not learn this until after I wrote a fair number of
bash scripts that use some Cygwin-specific stuff though.  But then one can
make a valid argument that it's useful to allow GNU tools to interface with
Windows on some level.  Also, I did not learn until later that Cygwin is
required to grovel into a number of undocumented / unsupported behaviors in
Windows, with no supported solution possible.  See: the problems with
forking.  No easy answers, apparently, but the Cygwin team seems to do a
good job working around them as best they can.

And in this case, they might be playing by the documented rules, for all I
know.  I haven't yet had time to delve into what Cygwin does differently
from the other shells I tried.  Maybe there is some uncommon pipe setting or
configuration that causes this issue...

Best regards,

James Johnston



--
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