Re: select()

[nikhilwiz@xxxxxxxxx]

On Tue, Jul 25, 2000 at 12:49:18PM +0530, Kedar Patankar wrote:
> That is not so. When you declare an fd_set, there is no way to set its
> size. I haven't checked the size of it yet, but fd_set is implemented
> as an array of ints internally.
> 

yeah... its implemented as an array of 1024 unsigned long ints. 1024 is the
FD_SETSIZE.

> The first argument is basically an optimization, to avoid having to look
> at all the bits in the fd_sets. An unfortunate side effect is that if you
> have only a few fds with big difference between their "integer" values,
> then the kernel ends up scanning a lot of "fd-space".
> 

i like the poll behavior better... where u specify which fds to scan and it
scans those and returns on a state change. but poll is emulated thru select on 
some old libc's ... ( < 5.4 ?)

> > > unnecessarily thru the intermediary fds, which seems like a waste of
> > > time to me. plz. tell me if i'm wrong somewhere...
> 
> What do you think can be the other solution? Accept an "array of integers,
> with each integer representing an fd to be watched"?? That would require
> moving *enormous* amounts of data across the kernel/user space for the
> fd_set. Right now, in each of the fd_set, each bit represents whether the
> corrosponding fd should be watched for the necessary condition.
> 

makes sense. I'm afraid i didn't go thru the source too thoroughly. I just went
thru it now, and i see what u see:

#define __FD_SETSIZE    1024
__fd_mask __fds_bits[__FD_SETSIZE / __NFDBITS];

yeah, i guess that makes a lot of difference in speed, between a bit and byte.
sounds like some of the optimisations i use in gfx...

> When you move from the fd_set to a new scheme with an array of fds (int),
> to be passed to select you have to move 32 times as much data across the
> user/kernel space when you call select.
> 

how is it _32_ times more data? int is only a WORD (16 bits)... ok.. if u 
consider setting the conditions as another 2 bits... that comes to 18.

> And on a busy web/proxy server, you can easily have tens of thousands of
> sockets to watch for, making the amount of data to be moved across for
> each socket expressed as an int (in the scheme you seem to propose) rather
> than as a bit in the current scheme, really enormous..
> 

agreed. wel... i didn't exactly _propose_ anything. I was just _wondering_. :)
thanx for clearing that up for me. 

That apart, i dunno if its a bug, but when i have 2 sockets open, and i run
select() on them, select is able to detect only the state change of the first
socket, and is failing to detect a read condition on the second one. poll() works
fine with them tho. I'm using 2.4.0-test2-ac2 (on Slackware 7, which i dont 
think makes any difference, as the calls are implemented in the kernel). I'm not
too sure i shud report it as a bug...

Nikhil.