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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-23 15:03:36

On Fri, 23 Dec 2005 10:17:00 -0000 (GMT)
"christopher baus" <christopher_at_[hidden]> wrote:

> 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.

Maybe on WAN servers, but not on high performance LAN based servers. 
Ruunning a simple test on 100 file descriptors, here is what I get.

poll() calls per second: 107906
select() calls per second: 104891
epoll() calls per second: 70923

Granted, it's not a huge difference, and other numbers of FDs show
differing results (also, only selecting for 1 FD in epoll() shows lots
better results, but you have to make more system calls as well.

Anyway, my point is that there surely are use cases where a user would
want control over which underlying implementation is used.  The
programmer should be allowed to determine which implementation is used
under the hood, and should be able to use several different ones for
several different uses.

I do not see this as exposing implementation details to the detriment of
encapsulation.  On the contrary, it gives the user the ability to have
finer control.  You can still default it to whatever you want, and if
the defaults are good enough, then fine.

> 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.

Why not?  The complexity would be exposing some mechanism to specify the
underlying implementation.  It doesn't have to be the implementation
itself, just some token representing an implementation.  Without the
ability to tell the library which implementation to use, this library is
severely lacking.

> 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.

That's fine, for default behavior, but I still argue that the programmer
should be given the ability to specify the underlying implementation.

> 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.

I know of at least 2 ;-)