Re: blocking socket is nonblocking after calling gnulib select() in windows

[Bruno Haible]

Hi Ray,

> Is the gnulib select() only intended to be used with nonblocking sockets on 
> windows?

Certainly not. The unit test (tests/test-select.c) tests both the blocking as
well as the non-blocking socket case.

> Wget uses sockets that are typically blocking, but 
> on return from rpl_select() those sockets are then non blocking. Based on a 
> trace and what I've read the cause of this is WSAEventSelect. As noted by 
> msdn:
> 
> "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 ioctlsocket or WSAIoctl 
> to 
> set the socket back to blocking mode."

I think you have found the reason for the behaviour your observed.

lib/select.c does
  WSAEventSelect ((SOCKET) h, NULL, 0);
but it does not then call ioctlsocket.

> So it looks like if rpl_select() will be used in Wget it will be necessary to 
> then call rpl ioctl immediately after  select() returns:
> const int zero = 0;
> ret = ioctl (fd, FIONBIO, &zero);

It would be better to fix lib/select.c, though.

> I read a bug-gnulib thread from a month ago where the end result is a new 
> module, nonblocking. Is that 100% reliable to determine whether or not a 
> socket 
> is blocking or not in windows?

Currently there is no API to determine whether a socket is blocking or not on
native Windows. It looks like that
  1. lib/select.c needs this information for proper operation,
  2. we will have to store this information in an array somewhere.

> If the nonblocking function is reliable to identify both blocking and 
> nonblocking sockets would it be worthwhile to incorporate that into gnulib's 
> select() so that the blocking state could be obtained and then restored 
> before 
> the function returns?

Yes, that would be the idea.

Also, I have to add that setting sockets to non-blocking for reading appears
not to work on native Windows; test-nonblocking-socket.sh fails.

Bruno
-- 
In memoriam Charles Delestraint 
<http://en.wikipedia.org/wiki/Charles_Delestraint>