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]

Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0


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


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