Re: rsync over ssh hang issue understood

[Darryl Miles <darryl-mailinglists at netbauds dot net>]

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/