bug-gnulib
[Top][All Lists]
Advanced

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

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


From: Ray Satiro
Subject: blocking socket is nonblocking after calling gnulib select() in windows
Date: Mon, 18 Apr 2011 22:33:11 -0700 (PDT)

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."

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.

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?

I'm not on the mailing list so please CC me on reply, Thanks




reply via email to

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