On Tue, Apr 19, 2011 at 7:33 AM, Ray Satiro <raysat...@yahoo.com> 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
