This is the mail archive of the cygwin-patches@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: Readv/writev patch


"Corinna Vinschen" <cygwin-patches@cygwin.com> wrote:
> Especially I'm reluctant to introduce your changes
> to the sendto and recvfrom implementation since I know there is
> a good reason to use the WinSock1 calls in the non-blocking case
> even though I don't recall why, right now.  Please skip that
> beautyifing patches and just add the readv/writev functionality.

I went back to the mailing list archives to see if I could dig up the
problem here and it seems that the code to fallback to the winsock1
calls in the non-blocking case was introduced as a result of the
discussion in the thread starting at
http://cygwin.com/ml/cygwin/2001-08/msg00617.html.  Interestingly, the
test program that demonstrated the "problem" was itself bogus.  Like,
you don't set the non-blocking flag w/ the following code:

  printf("Setting NONBLOCK\n");
  flags = fcntl (sock, F_GETFL, 0);
  flags &= O_NONBLOCK;
  ret = fcntl (sock, F_SETFL, flags);

Once that minor blot on the landscape is corrected, the sample programs
work fine; i.e. they do perfectly good non-blocking receives on UDP
sockets.

So, I'd guess that the issue about using WSARecvFrom and WSASendTo on
non-blocking sockets is a red herring and unless some other issue can be
found, would it be alright for me to re-submit my readv/writev socket
changes as initially submitted? i.e., with its beauty intact :-)

Cheers,

// Conrad




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