[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Remove set_windows_fd_as_blocking_socket()?

From: Ray Satiro
Subject: Re: [Bug-wget] Remove set_windows_fd_as_blocking_socket()?
Date: Wed, 06 Aug 2014 22:42:27 -0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0

On 8/6/2014 2:47 PM, Gisle Vanem wrote:
"Ray Satiro" <address@hidden> 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. ...

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]