X-Spam-Check-By: sourceware.org Message-ID: <44AE109E.3080003@netbauds.net> Date: Fri, 07 Jul 2006 08:43:26 +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: <005f01c6a164$37793650$a501a8c0 AT CAM DOT ARTIMI DOT COM> <44ADE056 DOT 307 AT netbauds DOT net> In-Reply-To: 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 Lev Bishop wrote: > On 7/7/06, Darryl Miles wrote: >> Dave Korn wrote: >> > On 07 July 2006 01:31, Darryl Miles wrote: >> The underlying socket is still being used in blocking mode. > > Socket?? What is this socket? Sorry s/socket/pipe/. >> Which means >> when we write write 1024 bytes of data but only one PIPE buffer is free >> (ulimit -p) a POSIX kernel would allow: > > What is "one PIPE buffer (ulimit -p)"? See below... >> Non-blocking: >> >> write(fd, buffer, 1024) = 512 >> write(fd, &buffer[512], 512) = -1 (EAGAIN) >> >> Blocking: >> >> write(fd, buffer, 1024) = 512 >> write(fd, &buffer[512], 512) = [blocking occurs until] 512 > > SUSv3 does not permit this behaviour. It is quite clear on this point: > "If the O_NONBLOCK flag is clear, a write request may cause the thread > to block, but on normal completion it shall return nbyte." Okay this is fine too. I believe the applications which we are seeing problems with are using non-blocking mode. >> I would guess under WIN32 we end up with fhandler.cc:raw_write() doing: >> >> WriteFile(hPipe, buffer, 1024, &writtenLen, 0) = [blocking occurs until] >> TRUE (writtenLen=1024) > > This gives the SUSv3-mandated behaviour for blocking pipes (modulo > signal-interruptibility). For POSIX blocking mode yes of course, but for POSIX non-blocking mode we are relying on the information coming back from NtQueryInformationFile to indicate that our WriteFile() won't block providing our writes are <= PIPE_BUF length. > What does "simulate 'ulimit -p'" mean? ulimit -p works just fine on cygwin: > $ ulimit -p > 8 I had a complete misunderstanding on that, I was thinking the application would tweak the kernel buffering between processes. But this appears to be just a reporting mechanism for PIPE_BUF size at runtime. What was the reason the existing code in CVS for select.cc was disabled? Maybe it would help to better understand the reasons/cases where the disabled code failed. 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/