On 8/6/2014 2:47 PM, Gisle Vanem wrote:
"Ray Satiro" <[email protected]> wrote:
How many times is select called?
AFAICR that would be 277.000 times too. I.e. only 1 loop through
set_windows_fd_as_blocking_socket().
That's fine then.
The function should only be called on a non-blocking socket to set it
blocking. It was needed because gnulib's select called
WSAEventSelect() which turns blocking sockets into non-blocking.
After every select call in wget the socket had to be turned back into
blocking because wget used blocking sockets.
True. MSDN [1] has this to say:
The WSAEventSelect function automatically sets socket s to
nonblocking mode, regardless of the value of lNetworkEvents. ...
But:
To set socket s back to blocking mode, it is first necessary to clear
the event record associated with socket s via a call to
WSAEventSelect with lNetworkEvents set to zero and the hEventObject
parameter set to NULL. You can then call ioctlsocketor WSAIoctl to
set the socket back to blocking mode.
I.e.: WSAEventSelect(NULL,0). So I fail to see why the current
wait-loop with is needed or even better. How can a 'ioctl (fd,
FIONBIO, &zero)'
be in-progress?
Yup, true. I quote that msdn remark in the e-mail I sent to gnulib devs.
But in these cases the sockets should have already been set with a null
event object so I omitted it from the function. Otherwise there'd be a
lot of unnecessary calls to WSAEventSelect(), like in your sample case
there'd be at least 277,000.
Now as to whether it's fine to omit the
WSASetLastError()/WSAGetLastError() I would caution you not to do that.
It is there to catch a corner case. If the ioctl fails and the error
code is WSAEINPROGRESS the socket was not converted back to blocking. In
that specific case we can wait and try again and eventually it will take
our call.
The alternatives are not appealing to me. I'm satisfied this method
gives wget best mix of reliability and performance, unless you can prove
otherwise.
Jay
