Icecast dev - Aug 2004 - libnet: sock_connected insists on a timeout

While working on integrating nonblocking IO into libshout, I noticed
that sock_connected cannot be called without blocking. If I read it
right, a timeout of zero will cause the call to block until the socket
is connected. So, my questions:

1. Am I reading this right?
2. How should I poll a pending connection?

I'd prefer to have a zero timeout act as a poll, but I don't know if
any other code is relying on the current semantics. If so, I guess I'd
have to add another interface. We could specify -1 to mean block
indefinitely, but I don't really see why we'd want to do that on a
nonblocking socket to begin with. Maybe if someone decided during
connect to switch to blocking I/O, but that's a stretch.

-b

On Monday 26 July 2004 11:48, Brendan Cully wrote:
> While working on integrating nonblocking IO into libshout, I noticed
> that sock_connected cannot be called without blocking. If I read it
> right, a timeout of zero will cause the call to block until the socket
> is connected. So, my questions:
>
> 1. Am I reading this right?
No. The timeout value (in seconds) gets put into a struct timeval.

This timeval gets passed directly to select().

Select() has 2 behaviours defined:

non-null timeval: block for up to this length of time. If { 0, 0 } is passed
in, then, this means "don't block".
null timeval: block indefinately.

We don't special-case zero to pass null, so passing zero will just never
block.

Maybe the comment above the function should say "pass zero as timeout if
you
don't want it to block).

We might also consider allowing negative values to actually mean "block
forever" (special-cased to pass NULL), but I agrew with you that it's
unlikely anyone wants to do that.

Mike

<200407261244.30032.msmith@xiph.org>
Message-ID: <20040726024801.GA18890@watanabe.local>

On Monday, 26 July 2004 at 12:44, Michael Smith wrote:
> On Monday 26 July 2004 11:48, Brendan Cully wrote:
> > While working on integrating nonblocking IO into libshout, I noticed
> > that sock_connected cannot be called without blocking. If I read it
> > right, a timeout of zero will cause the call to block until the socket
> > is connected. So, my questions:
> >
> > 1. Am I reading this right?
>
> No. The timeout value (in seconds) gets put into a struct timeval.
>
> This timeval gets passed directly to select().
>
> Select() has 2 behaviours defined:
>
> non-null timeval: block for up to this length of time. If { 0, 0 } is
passed
> in, then, this means "don't block".
> null timeval: block indefinately.
>
> We don't special-case zero to pass null, so passing zero will just
never
> block.
are we looking at the same code?

int sock_connected (int sock, unsigned timeout)
{
fd_set wfds;
int val = SOCK_ERROR;
socklen_t size = sizeof val;
struct timeval tv, *timeval = NULL;

if (timeout)
{
tv.tv_sec = timeout;
tv.tv_usec = 0;
timeval = &tv;
}

FD_ZERO(&wfds);
FD_SET(sock, &wfds);

switch (select(sock + 1, NULL, &wfds, NULL, timeval))

that looks like a special case to me.

<200407261244.30032.msmith@xiph.org>
<20040726024801.GA18890@watanabe.local>
Message-ID: <200407261259.25547.msmith@xiph.org>

On Monday 26 July 2004 12:48, Brendan Cully wrote:
> > We don't special-case zero to pass null, so passing zero will just
never
> > block.
>
> are we looking at the same code?
Nope :-)

I had an outdated libshout checkout. This change was made by Karl earlier this
year. Not sure why.

Mike