Mail Archives: cygwin/2006/06/30/04:48:08
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/
- Raw text -