Re: rsync over ssh hang issue understood

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

Christopher Faylor wrote:
> On Sat, Jul 01, 2006 at 11:05:24AM -0400, Christopher Faylor wrote:
> Since I'm not getting any nibbles when I talk about "the person
> responsible" here, I guess he must be long gone by now.
>
> So, his pipe code, which seemed to be based on correct concepts, is
> basically up for grabs for some enterprising soul to either take it the
> rest of the way or prove that it can't be made to work.

I've done as you have asked and investigated as much as I can into the 
current solution using NtQueryInformationFile().


However according to MSDN this function is undocumented.  This means a 
number of things:

 * There is no contractual specification with the API.

 * There is therefore no guarantee MS won't change its behavior between 
patch levels and builds.  Infact I think this problem has been pointed 
out to this list before due to problems between specifics ServicePacks.

 * There is therefore no guarantee the next version of Windows will 
support it at all.

 * There is therefore no guaranteed meaning to the return values.

 * Maybe a MS rocket scientist is watching this last and would be able 
to provide some authoritative understanding of how this function call 
works between different windows versions.  Maybe the original author got 
the idea out of a "behind the scenes" book on Win32 API and tested out a 
hunch.


I would appreciate your thoughts on this situation now I have clarified 
it as I see it.  There is no point basing the very specific behavior 
semantics of POSIX pipes on the building blocks of undocumented API calls.

I personally have no more interest or time in resurrecting this solution 
and will continue to work on a new solution.


The proposed solution I was putting forward uses documented APIs and 
Overlapping I/O in the way MS had intended.  The blocking/throttling 
nature of POSIX is manufactured from wait queues implemented with native 
Mutex/Event objects.

The biggest drawbacks to my proposal is the double buffering that will 
occur for all written data.  I do not expect the Mutex/Event overhead to 
get in the way for the most common case.  I have no problem in taking 
that performance hit to get a working POSIX pipe.


Darryl

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/