This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]