This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: rsync over ssh hang issue understood

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.

I don't know enough about real life use of the WIN32 API to know if an
overlapped IO can block as well.  If that is the case then maybe all
pipe IO has to be done through a writer thread and we use the busyiness
state of a writer thread to drive set/reset write_ready state for
select.  We then serialize all write(2) calls on pipes in FIFO order so
there is a clear defined order, even if the application happens to have
multiple threads writing.

Maybe someone with more WIN32 knowledge than me would care to comment.

Bear in mind, you can only set overlapped vs non-overlapped IO at file-handle creation time and subsequently the mode cannot be changed (or even determined, in any convenient way). Cygwin uses windows pipes so we can interoperate with native windows processes, which use non-overlapped syscalls on inherited handles (and which fail on overlapped handles). If you go with overlapped handles, then you're removing the compatibility with native processes, which thereby removes the main justification for using native pipes, and instead it would almost certainly be better (less work and more efficient) to implement pipes from scratch using shared memory and semaphores or similar primitives.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]