[Subject Prev][Subject Next][Thread Prev][Thread Next][Subject Index][Thread Index]
> yes, the first argument is very important. This is the only way to know
> how many members are there in the fd_set array you have provided. Please
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.
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".
> > 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.
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.
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..
Compared to that the current scheme is pretty OK. Its a classic time/space