This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: 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: Mon, 23 Dec 2013 19:31:10 -0000
- Subject: RE: Pipe syncronization and incompatibility between Cygwin and .NET Framework 4.0
- Authentication-results: sourceware.org; auth=none
- References: <02ee01cefdce$9c343300$d49c9900$ at motionview3d dot com> <5F8AAC04F9616747BC4CC0E803D5907D0C455040 at MLBXv04 dot nih dot gov> <030c01cefff6$9c1fa3c0$d45eeb40$ at motionview3d dot com> <5F8AAC04F9616747BC4CC0E803D5907D0C457767 at MLBXv04 dot nih dot gov>
> > 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
that
> 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
console
> 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
things
> 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
on
> 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,
rather
> 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