This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: rsync over ssh hang issue understood
- From: Darryl Miles <darryl-mailinglists at netbauds dot net>
- To: cygwin at cygwin dot com
- Date: Fri, 07 Jul 2006 05:17:26 +0100
- Subject: Re: rsync over ssh hang issue understood
- References: <005f01c6a164$37793650$a501a8c0@CAM.ARTIMI.COM>
Dave Korn wrote:
On 07 July 2006 01:31, Darryl Miles wrote:
Maybe you are in a better position to share more insight into the
situation (specifically about the use of NtQueryInformationFile in
addressing the writability semantics of the POSIX select/poll/write
event system).
I think you should just use it and it should just work.
Okay the immediate red flag I can see with it:
else if (fpli.WriteQuotaAvailable >= PIPE_BUF)
gotone += s->write_ready = true;
The underlying socket is still being used in blocking mode. Which means
when we write write 1024 bytes of data but only one PIPE buffer is free
(ulimit -p) a POSIX kernel would allow:
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
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)
Maybe PIPE_NOWAIT would be good for us (to setup when the fd has
O_NONBLOCK set).
If PIPE_NOWAIT isn't good for us. We can get around this by using
Overlapping I/O and controlling the outstanding pipe buffers. This
makes cygwin simulate 'ulimit -p' to some degree. Which is back towards
my proposal.
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/