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
At 12:49 PM 4/2/2004 +0200, Corinna Vinschen wrote:
>So, one of the above patches (or both together?) should solve the problem.
>Needless to say that both work fine on my machine so I won't say that.
1) First patch: works better, e.g. will complete most of the time under
strace and with cvs -t. However it still hangs otherwise, and sometimes
under strace. From the trace I saw it was hanging at the readv, as reported
before. Another time when I hit ^C, I triggered the try_to_debug in the
wait routine ("what" was = 1). This indicates that the event wasn't set
when it should and wait got released by signal_arrived.
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.
3) Second patch: From the strace produced in 1), I can see that close has
nothing to do with this. The socket is closed MUCH later. So I didn't try
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.
Pierre