This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
- From: "James Johnston" <JamesJ at motionview3d dot com>
- To: <cygwin at cygwin dot com>
- Date: Fri, 20 Dec 2013 21:58:24 -0000
- Subject: Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
- Authentication-results: sourceware.org; auth=none
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