[Top][All Lists]
[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
- blocking socket is nonblocking after calling gnulib select() in windows,
Ray Satiro <=
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/19
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bruno Haible, 2011/04/19
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Eric Blake, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Bastien ROUCARIES, 2011/04/20
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Paolo Bonzini, 2011/04/21
- Re: blocking socket is nonblocking after calling gnulib select() in windows, Ray Satiro, 2011/04/21