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:subject:date:message-id:mime-version
	:content-type:content-transfer-encoding; q=dns; s=default; b=Zor
	YiCE8nh9IVfneyddO8Za74EDOVC/sUcjuBVp49e6WOiurMUoFlUikv+DzvbktmCa
	P6xuOFn+lDQFJIMj16RHV1bsx5K2rKIZ2SlDl7fKRiyQ7EJNw3ly2+w9lFwMOVn6
	0Cx0EcSMtTL6V7Vcwg1p3jvJu19147jGNrrv/tZg=
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:subject:date:message-id:mime-version
	:content-type:content-transfer-encoding; s=default; bh=UhL7+vOMe
	CrkcaHaeQtjX8SRfe4=; b=yKOVbHthCoTBI6MCJK2pdDZFNQwT4Z5I7WJX/oKkw
	weqJ6nF6LQzc+HDOM/8f3avgkSftcyxekO5VoBbwqV0rdagqupYevUdGVP5tp6Fn
	YdD0p7MpwfGL2JvXRASJz+d17wIU+NIw6xy1BS+FtJoyzv9LejYE5imDhMDg+TNs
	es=
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.9 required=5.0 tests=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>
Subject:	Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
Date:	Fri, 20 Dec 2013 21:58:24 -0000
Message-ID:	<02ee01cefdce$9c343300$d49c9900$@motionview3d.com>
MIME-Version:	1.0
X-IsSubscribed:	yes

Hi,

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.

// File ReaderCPP.cpp
// The following code was compiled in Visual C++ 2008.  However,
// I expect any standard Windows compiler to suffice.

#include <windows.h>

int main()
{
    HANDLE hIn = GetStdHandle(STD_INPUT_HANDLE);

    // NOTE:  NETFX 4.0 introduced these calls to PeekNamedPipe
    // and WaitForMultipleObjectsEx.  NETFX 2.0 would just go
    // straight to ReadFile.  The reasoning in the NETFX 4.0 source
    // source code for the change was to support aborting the
    // thread.

    // Program will not hang if this code is removed:
    DWORD read, avail, left, written;
    PeekNamedPipe(hIn, NULL, 0, &read, &avail, &left);

    // This function never unblocks if PeekNamedPipe is called
    // and we are in Cygwin.  It works fine from msysGit's bash
    // and also works fine from cmd.exe.
    WaitForMultipleObjectsEx(1, &hIn, TRUE, INFINITE, TRUE);

    // Echo output (for debug purpose)
    char buf[1000];
    ReadFile(hIn, buf, 1000, &read, NULL);
    WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buf, read, &written, NULL);
    return 0;
}

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 suspect there is a race condition as sometimes
some NETFX 4.0 programs don't hang, and sometimes they do.  This test case
seems to hang 100% reliably on my system, however. 

I tested under these configurations:

 * ReaderCPP always compiled with Visual C++ 2008.  (Other compilers will
probably yield identical results.)
 * Cygwin with setup updated and all pending packages installed today, and I
used the latest Cygwin1.dll snapshot as of today:  fails; ReaderCPP hangs.
 * Released version of Cygwin from a few months ago:  fails.
 * Same command run from msysGit's bash:  works fine; ReaderCPP exits after
3 seconds and echoes input, as expected.
 * Running "echo test | ReaderCPP" from Windows command prompt: works fine.

Seems like Cygwin is doing something different with the standard input pipe
compared to other non-Cygwin shells that causes this synchronization issue
and causes WaitForMultipleObjectsEx to hang, even though there is pending
input after 3 seconds.  Does anyone else reproduce this?  Any ideas why or
what the fix might look like?  Thank you for any feedback.

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 -