On Sep 11 14:20, Bob Byrnes wrote: > When the inbound transfer stalls, I see sftp performing a blocking > read on the ssh->sftp pipe. It seems to be reading 16k chunks (even > though the default buffer size is supposed to be 32k ... see below). > > ssh is using select to monitor both pipes and the socket, but the > ssh->sftp pipe doesn't select writable for long periods of time, > because NtQueryInformationFile reports that the pipe is full. > That's odd: why isn't the data in transit within the pipe delivered > to the reading sftp process?
Do I understand that right? sftp is in the blocking read on the pipe, there is data in the pipe and nevertheless read doesn't return? That's odd. > But the docs also say that "Write-through mode ... affects only write > operations on byte-type pipes and, then, only when the client and server > processes are on different computers." I guess this means that local > pipes always do buffering as described in the previous paragraph, and > this can't be disabled using FILE_FLAG_WRITE_THROUGH. Did you try that? > So, what should we do now? We need a reliable way to tell if writes > will block, for both select and nonblocking I/O. I've been using > NtQueryInformationFile to see how much space is available (analogous > to use of PeekNamedPipe for reads), but we need to control how pipe > buffering is done. > > I'll do some experiments ... maybe we can use something like FlushFileBuffers > before NtQueryInformationFile to induce data transfer to any pending reads on > the other side of the pipe, although I'm concerned that this might block > when there is no pending read, and that would be bad. > > Other, better ideas would be most welcome! Dunno if that's a *better* idea, but would it be reasonable to try changing pipes to use overlapped I/O? Or what if a read from a pipe always asks for the number of available bytes using NtQueryInformationFile and then only actually reads this number of bytes and returns that to the caller? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:[EMAIL PROTECTED] Red Hat, Inc.
