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