Mail Archives: cygwin/2006/06/29/22:02:26
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/
- Raw text -