X-Spam-Check-By:	sourceware.org
Message-ID:	<44AD884A.6010201@netbauds.net>
Date:	Thu, 06 Jul 2006 23:01:46 +0100
From:	Darryl Miles <darryl-mailinglists AT netbauds DOT net>
User-Agent:	Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.0.4) Gecko/20060614 SeaMonkey/1.0.2
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: rsync over ssh hang issue understood
References:	<44A348D1 DOT 6070908 AT netbauds DOT net> <ba40711f0606291839p2e1d7b10l7befd8cf2cc2d1a7 AT mail DOT gmail DOT com> <44A507F8 DOT 4030409 AT netbauds DOT net> <44A53F4B DOT 4070503 AT netbauds DOT net> <20060701021306 DOT GB25372 AT trixie DOT casa DOT cgf DOT cx> <44A682A4 DOT 2000005 AT netbauds DOT net> <20060701150524 DOT GA13489 AT trixie DOT casa DOT cgf DOT cx> <20060702021242 DOT GA21318 AT trixie DOT casa DOT cgf DOT cx>
In-Reply-To:	<20060702021242.GA21318@trixie.casa.cgf.cx>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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/

- Raw text -