This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: PLEASE TEST: New implementation of blocking socket I/O
Hi Pierre.
On Apr 2 20:55, Pierre A. Humblet wrote:
> At 12:49 PM 4/2/2004 +0200, Corinna Vinschen wrote:
> 2) Then I tried the following:
> case WSA_WAIT_EVENT_0:
> why = WSAEnumNetworkEvents (sock, event, &evts);
> if (!why)
> {
> if (!evts.lNetworkEvents)
> return 0;
> The idea is that the reenabling function is called, which should help.
> It ran without problem 8 times in a row, when I prudently declared victory.
> >From strace it did 522 writes (size 1024) to the same socket.
Hmhm, that's interesting. But that's all very ugly, isn't it?
> 4) I have put extra printf in ::sendmsg to see if WSASentTo can return
> success with ret > 0 and WSAEWOULDBLOCK. The answer is negative, WSASendTo
> behaves like the MS sendto. That means that it's not necessary to initialize
> ret and to test ret > 0. I tested that.
> Note that if those were really necessary after all, then the current code
> would misbehave when is_nonblocking () is true.
I've reread the WSASendTo man page and now I see that I probably
misinterpreted the following sentence:
"If the socket is nonblocking and stream oriented, and there is not
sufficient space in the transport's buffer, WSASendTo returns with
only part of the application's buffers having been consumed."
It doesn't indicate at all that WSAEWOULDBLOCK gets set in that
situation.
Thanks for your testing. However, I'm going to revert to overlapped
I/O. After having tried it now, I think overlapped is the better
solution. Overlapped doesn't need a loop, it's shorter and looks far
more straightforward. Sigh. So many hours for nothing. I'm wondering
if testing async I/O was good for something, though.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Developer mailto:cygwin@cygwin.com
Red Hat, Inc.