X-Spam-Check-By: sourceware.org Message-ID: <44AD884A.6010201@netbauds.net> Date: Thu, 06 Jul 2006 23:01:46 +0100 From: Darryl Miles 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> <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> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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/