Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0

James Johnston JamesJ@motionview3d.com
Mon Dec 23 19:32:00 GMT 2013

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

More information about the Cygwin mailing list