[ECOS] select () confusion

[ECOS] select () confusion

[Trenton D. Adams]

What does the following statement in the select () function
documentation mean?

n is the highest-numbered descriptor in any of the three sets, plus 1.

Does that mean I have to figure out what the highest numbered socket is
before calling select?

Anyhow, I thought that the first parameter was the number of file
descriptors in the fd_set.  It makes no sense to have to calculate what
the highest numbered socket descriptor is before calling select ().  On
top of that, the example at the bottom of the documentation for select
() is not very good.  It passes a 1 in as the first parameter which is
exactly why I thought it was the number of file descriptors and not the
highest numbered one.

Trenton D. Adams
Embedded Developer
Windows Developer
Extreme Engineering Ltd.
Calgary Alberta

Phone: 403 640 9494 ext 208
Fax:   403 640 9599

Re: [ECOS] select () confusion

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
> What does the following statement in the select () function
> documentation mean?
> 
> n is the highest-numbered descriptor in any of the three sets, plus 1.
> 
> Does that mean I have to figure out what the highest numbered socket

*you are selecting on*

> is
> before calling select?

Yes. Normally you track the largest fd you've ever had, or keep a list of
fds. Or just use FD_SETSIZE if you're lazy IIRC.
 
> Anyhow, I thought that the first parameter was the number of file
> descriptors in the fd_set.  It makes no sense to have to calculate what
> the highest numbered socket descriptor is before calling select ().

It's standard BSD select() use.

> On
> top of that, the example at the bottom of the documentation for select
> () is not very good.  It passes a 1 in as the first parameter which is
> exactly why I thought it was the number of file descriptors and not the
> highest numbered one.

Ah, that's because it happens to choose stdin, which is always fd 0.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] select () confusion

[Trenton D. Adams]

  > 
  > Yes. Normally you track the largest fd you've ever had, or keep a
list
  > of
  > fds. Or just use FD_SETSIZE if you're lazy IIRC.
  > 

IIRC?

  > > Anyhow, I thought that the first parameter was the number of file
  > > descriptors in the fd_set.  It makes no sense to have to calculate
  > what
  > > the highest numbered socket descriptor is before calling select
().
  > 
  > It's standard BSD select() use.
  > 

Not *_ALL_* standards are a good idea! ;)

I personally like the windows, BSD *compatible*, select better.  The
first parameter is there only for compatibility.  Since FD_SET always
increments the fd count anyhow, I don't see a point in even using the
first parameter.

  > > On
  > > top of that, the example at the bottom of the documentation for
select
  > > () is not very good.  It passes a 1 in as the first parameter
which is
  > > exactly why I thought it was the number of file descriptors and
not
  > the
  > > highest numbered one.
  > 
  > Ah, that's because it happens to choose stdin, which is always fd 0.
  > 

Oh, I see.

Re: [ECOS] select () confusion

[Jonathan Larmour]

"Trenton D. Adams" wrote:
> 
>   > Yes. Normally you track the largest fd you've ever had, or keep a
> list
>   > of
>   > fds. Or just use FD_SETSIZE if you're lazy IIRC.
>   >
> 
> IIRC?

If I recall correctly.

> I personally like the windows, BSD *compatible*, select better.  The
> first parameter is there only for compatibility.

Yeah, that's because the reason it was there originally was for efficiency,
and we know that's not relevant for Windows ;).

>  Since FD_SET always
> increments the fd count anyhow, I don't see a point in even using the
> first parameter.

Eh? FD_SET doesn't change the value of the highest fd you will be selecting
on, or the number of fds you have. It just sets a bit in a bitmask (the
fdset).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] select () confusion

[Trenton D. Adams]

  > 
  > Yeah, that's because the reason it was there originally was for
  > efficiency,
  > and we know that's not relevant for Windows ;).
  > 
LMAO, I agree.  But, doesn't that assume that the programmer actually
knows how to program efficiently?  I mean wouldn't it be more efficient
for someone that knows what efficient is to do this internally?

  > >  Since FD_SET always
  > > increments the fd count anyhow, I don't see a point in even using
the
  > > first parameter.
  > 
  > Eh? FD_SET doesn't change the value of the highest fd you will be
  > selecting
  > on, or the number of fds you have. It just sets a bit in a bitmask
(the
  > fdset).
  > 

Oh, I was referring to the windows docs.  I guess they are completely
different.  I can definitely see why that would be efficient now.  After
all, an fd_set in eCos is only an array of integer masks.  Bit
manipulation is much faster than going through an array of SOCKETs.

eCos fd_set
typedef	struct fd_set {
	fd_mask	fds_bits[__howmany(FD_SETSIZE, __NFDBITS)];
} fd_set;

windows fd_set (LMAO, they suck)
typedef struct fd_set {
  u_int    fd_count;                 // how many are SET? 
  SOCKET   fd_array[FD_SETSIZE];     // an array of SOCKETs 
} fd_set;


And, infact windows does increment an fdcount! :) LOL