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

[Bastien ROUCARIES]

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