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

[Bastien ROUCARIES]

Need to test but it seems I have something:

SIO_ADDRESS_LIST_CHANGE (opcode setting: V, T==1)
To receive notification of changes in the list of local transport
addresses of the socket's protocol family to which the application can
bind. No output information will be provided upon completion of this
IOCTL; the completion merely indicates that list of available local
address has changed and should be queried again through
SIO_ADDRESS_LIST_QUERY.

It is assumed (although not required) that the application uses
overlapped I/O to be notified of change by completion of
SIO_ADDRESS_LIST_CHANGE request. Alternatively, if the
SIO_ADDRESS_LIST_CHANGE IOCTL is issued on a non-blocking socket and
without overlapped parameters (lpOverlapped/ lpCompletionRoutine are
set to NULL), it will complete immediately with error WSAEWOULDBLOCK.
The application can then wait for address list change events through a
call to WSAEventSelect or WSAAsyncSelect with FD_ADDRESS_LIST_CHANGE
bit set in the network event bitmask.

According to http://msdn.microsoft.com/en-us/library/ms741621(v=vs.85).aspx

need to test but could work

On Tue, Apr 19, 2011 at 4:41 PM, Bastien ROUCARIES
<address@hidden> wrote:
> On Tue, Apr 19, 2011 at 7:33 AM, Ray Satiro <address@hidden> wrote:
>> Hi,
>>
>>
>> Thank you all for your continuous work on gnulib. Every time I look at it 
>> it's
>> evolving.
>>
>> Is the gnulib select() only intended to be used with nonblocking sockets on
>> windows? The Wget project has recently switched to gnulib's replacement 
>> select
>> function in their dev builds. 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."
>
> Exactly
>
>>
>> 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);
>>
>>
>> But is that acceptable or is gnulib select only intended to work with
>> nonblocking sockets?
>>
>>
>> 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? I'd read some time ago that windows sockets 
>> did
>> not have that api to determine whether or not the socket is blocking because
>> internal winsock functions can take a socket that is set one way and 
>> temporarily
>> set it another. Unfortunately I do not recall a source for this.
>
> Yes but it seems that a least C# know when socket is non blocking. Yes
> you could help but we are clueless how to determine
>
> Bastien
>