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=JUPIGrA/xPbM7QOZKrxHK/IcBrePHS4xBkVv6lUStni
	0BFcb3krmpihsrLawO2mR/XWKMyi6XGdrahRBZ9LBqlCFXGfl4XzEyDaRshx3yW2
	/hOqb7LpKYTEYIKaqKaJqZ1PvaM8EAA65lh0lLOpQsWNRwDm79SpzElfq16u+vMY
	=
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=GKORfpEhiKyU8EGqU1zcvcZVSv8=; b=cFbmQ/r5HZa9WnXyc
	fp8ZiV99k/9CPJ2GYhXJrbLT4FRzZqhXQlUfm/EiXtTR3O0bhd2euGEYXFgYepzW
	ZDkIrcib0l5L13fM3Wstg4Ys0AzT++HQ5A9NM3kLXARHX/6SM2uSQQEEJ/RSPSN+
	frI4ChOqb29dsapIADGkgOGqKc=
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=-0.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham 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>
In-Reply-To:	<02ee01cefdce$9c343300$d49c9900$@motionview3d.com>
Subject:	RE: Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
Date:	Mon, 23 Dec 2013 23:05:39 -0000
Message-ID:	<034b01cf0033$806f8cc0$814ea640$@motionview3d.com>
MIME-Version:	1.0
X-IsSubscribed:	yes

> I am calling a few different .NET Framework 4.0 command line tools from
> Cygwin and have noted that .NET Framework 4.0 introduced a change that
> causes an incompatibility between it and Cygwin.  I have carefully
examined
> .NET Framework 4.0 source code and also checked things out with an API
> monitor utility, and have arrived at a simple test case in straight Win32
C
> code.
> 
> <snip test case that calls WaitForSingleObject with unsupported pipe
handle>
> 
> Then run this from bash shell:
> 
> ( sleep 3 ; echo test ) | ./ReaderCPP
> 
> This issue will affect every .NET Framework 4.0 program that attempts to
> read from standard input.

I narrowed down the problem.  The stdin file handle inherited by the
non-Cygwin program ReaderCPP is an overlapped file handle.  I wrote a simple
Win32 C test case that uses CreateNamedPipe & CreateFile like Cygwin does in
fhandler_pipe::create in pipes.cc file.  The test case opens both handles
with FILE_FLAG_OVERLAPPED.  It then calls CreateProcess to start WriterCPP
(containing a Sleep & a WriteFile to stdout) and the existing ReaderCPP
program.  The pipe is used to connect WriterCPP's stdout to ReaderCPP's
stdin.  This causes ReaderCPP to hang, just like it was when called from
Cygwin.  If I remove the problematic WaitForMultipleObjectsEx call from
ReaderCPP, then everything works normally.  Alternatively, if I modify the
program to NOT open pipes in overlapped mode, the WaitForMultipleObjectsEx
is no longer a problem - pointing to the solution.  I can send sample code
if it would be helpful to anyone.

As far as I'm aware, this practice of passing overlapped standard file
handles to Win32 child processes is probably unique to Cygwin.  The standard
CMD.EXE doesn't do it, for example.  One reason why this probably MUST be
the case is given in the MSDN docs for ReadFile:

"A pointer to an OVERLAPPED structure is required if the hFile parameter was
opened with FILE_FLAG_OVERLAPPED, otherwise it can be NULL."

This is further confirmed in the remarks ("The lpOverlapped parameter must
not be NULL").  Because probably every Win32 program in existence isn't
normally using overlapped I/O with their standard file handles, this causes
all of them to exhibit undefined behavior.

The bottom line is that .NET Framework 4.0 programs will hang when they try
to read from standard input unless Cygwin can give them pipe handles that
were NOT opened with overlapped I/O.  Also, any standard Win32 program will
exhibit undefined behavior because most (all?) Win32 C runtime libraries do
not use overlapped I/O with the standard file handles.  This will require
modifications to Cygwin.  It seems that fhandler_pipe::create needs to NOT
create overlapped pipes - at least in the case of pipes destined for
standard Win32 programs' stdin.  That might be easier said than done,
however.  On the other hand, a blanket change of removing
FILE_FLAG_OVERLAPPED carries the risk of breaking existing code in Cygwin -
I don't know how catastrophic such a change might be.

Any ideas?  If removing this flag causes breakage only in rare edge cases or
results in non-POSIX behavior (or no breakage at all), perhaps this behavior
can be customized via a flag in the CYGWIN environment variable.  On the
other hand, if removing the flag causes mass breakage, I am not sure what
the solution should be.

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

- Raw text -