Re: [boost] [review] Asio formal review.

From: christopher baus (christopher_at_[hidden])
Date: 2005-12-23 05:17:00

> On Thu, 22 Dec 2005 21:16:11 -0000 (GMT)
> "christopher baus" <christopher_at_[hidden]> wrote:
>
>
>> Interesting.  Could you give an example where select() is faster than
>> epoll()?  I suspect it is with smaller numbers of file descriptors.
>
>
> OK.  I have a small example (but I'm out of time to do more).  The
> problem with epoll() is when you have a large number of FDs that are all
> ready.  If you epoll_wait() for as many events as you have FDs you get
> MUCH worse performance than poll() or select.  If you just wait on 1 FD
> with epoll_wait(), you can call the system call a bunch more times, but
> then again, you have to make a system call for every FD that is ready,
> which is more expensive over lots of FDs.

Ok I could see that being the case.  The /dev/poll, kqueue, epoll
interfaces are all attempts to address the linear search of the FD array. 
For instance if there are a large number of FDs being waited on, but the
last one is notified repeatedly, then many long searches are required to
find the ready FD.

But if all the FDs are ready, then no search is required.  Basically all
you have to do is call the handler for each FD.  So yes, in the case where
there  are a lot of FDs that are always ready, then select is probably
faster because it requires fewer sys calls, and no searching.

I do think that is probably a rare case though, especially on internet
facing servers.  Plus epoll allows edge triggering to prevent being
re-notified of readiness events.  But you do have a point here.  I always
just thought "epoll better" but now I see specific cases where that might
not be true.

The problem is it is really difficult to decide which will be better for
most users.  I could almost see the same app allowing both epoll and
select with the same binary, but I'm not sure the complexity is worth it.

I've read a few of Rene's and Chris's comments on configuring for
epoll/select, and my feeling is that on Linux if epoll is there, use it. 
But it is also possible to test for the existence of epoll at run time so
the same binary can run on 2.4 and 2.6 kernels.

I don't know of any apps that purposefully choose to use select() in the
presence of epoll(), if an epoll() implementation for the app is
available.  If anything most app developers have been scrambling to
provide epoll() support.

christopher