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/
