X-Spam-Check-By: sourceware.org Date: Fri, 30 Jun 2006 22:13:06 -0400 From: Christopher Faylor To: cygwin AT cygwin DOT com Subject: Re: rsync over ssh hang issue understood Message-ID: <20060701021306.GB25372@trixie.casa.cgf.cx> Reply-To: cygwin AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com References: <44A348D1 DOT 6070908 AT netbauds DOT net> <44A507F8 DOT 4030409 AT netbauds DOT net> <44A53F4B DOT 4070503 AT netbauds DOT net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44A53F4B.4070503@netbauds.net> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: 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 On Fri, Jun 30, 2006 at 04:12:11PM +0100, Darryl Miles wrote: >Darryl Miles wrote: >>There maybe other ways to deal with that write() but as far as I >>understand the NT kernel does not provide a true non-blocking mechanism >>to work from with pipes. This is where you can offer to the kernel the >>data and if the buffers are full the kernel will reject the data without >>blocking leaving the application holding it. Overlapped I/O as I >>understand it does not work like this. > >Okay the biggest factor I overlooked here was that the memory buffer >inside application space is pinned until IO completion is signalled, so >the theory here must be that for any real world usage I'd run out of >application address space before the kernel hit any internal problems. >As there is little overhead inside the NT kernel per overlapped IO that >is queued up compared to the 1kb/4kb buffer within application address >space. I chimed in earlier in this thread because I didn't want you to start working on an implementation which I'd have to reject at some later point. I just want to be clear here. I really do want to be convinced that the current implementation in cygwin can't be fixed before we scrap that and implement something new. The person who submitted the original change thought that it should be possible to fix the problem but he never followed through with a fix. cgf -- 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/