Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
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
> 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
> 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
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...
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin