[EMAIL PROTECTED] wrote:
> amos shapira wrote:
Maybe using poll(2) will help you around that (I also heard that poll is
generally more efficient because it helps the kernel avoid having to
re-interpret the syscall parameters on every call).
this is interesting. can anyone provide more info on this?
the problem with select, is that it is unable to optimize handling of
'holes' in the file descriptor set.
suppose that you need to select on file descriptors 2 and 4000.
you need to pass info about all file descriptors up to 4000 (i.e. many
'0' bits, and only two '1' bits, in the different select sets).
with poll, you pass an array of the descriptors you care about. so the
size of the array is proportional to the amount of descriptors you are
interested in, while with select it is proportional to the numeric value
of the largest descriptor you are interested in.
note that this is relevant only for applications that have many open
sockets.
when you use poll, you can use the trick of having 2 theads - one polls
on "idle" sockets (i.e. sockets that did not have I/O in the last X
seconds), and one listens on 'active' sockets (i.e. sockets that had I/O
in the last X seconds). this avoids the major problem with both select
and poll - that after an event on a single socket, the info for all the
sockets has to be copied to user space (when select/poll returns), and
then to kernel space again (when invoking poll/select again).
i think that people added epoll support in order to avoid waking the
poll function altogether - by receiving a signal form the kernel with
the exact info, instead of having to return from poll.
--guy
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
