Re: rsync over ssh hang issue understood

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Jun 29 22:01, Lev Bishop wrote:
> On 6/29/06, Darryl Miles wrote:
> 
> >I also think from reading through the WIN32 API that I either get
> >blocking IO or overlapped IO, where overlapped is non-blocking with
> >async I/O completion signaling.  This mode isn't directly compatible
> >with non-blocking of Unix the way I see it as the data is still queued
> >into the kernel for IO.  Not next left with the application in the case
> >of errno=EAGAIN of unix.
> 
> Actually, the data is left with the application, but the application
> is not allowed to touch it until the write has completed. It's very
> similar to UNIX asynchronous IO (aio_read() aio_write() et al).
> 
> However for pipes (and only for pipes) the windows API offers
> something a lot like UNIX nonblocking semantics. It's only supported
> to provide Lan Manager 2.0 compatibility and MSDN says should never be
> used. Look at SetNamedPipeHandleState() with the PIPE_NOWAIT flag.
> Unlike Overlapped IO (see below) the PIPE_NOWAIT flag can be switched
> on and off at will, it seems, so maybe there's a way to use it to do
> what you want.

There's a tiny problem with overlapped I/O which spoils the fun a bit.

2 years ago I had socket I/O implemented using overlapped I/O to get
socket I/O interuptible by signals.  It worked quite nicely, up to the
point where the call was actually interrupted by a signal, the
overlapped call hadn't finshed, and CancelIO had to be called to
interrupt the action.  The problem is this:  There's no way to find
out how many bytes actually were transmitted in case of canceling the
Winsock send() call.

Cygwin's send() could only return -1/EINTR, so the application assumed
that the data has to be completely retransmit and called send() again
with the full block of data.  Out of sync, too bad.

I can easily imagine that we could get the same problem with pipes.
You can argue that the overlapped I/O should never get canceled and
that send() should always return as if all data has been send.  The next
send() then has to wait until the previously started overlapped I/O
gets finished, returning -1 on signal.  But what if the still running
overlapped I/O from the previosuly called send() returns with error?
Out of sync again.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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/