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

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-23 20:49:02

Hi Jody,

--- Jody Hagins <jody-boost-011304_at_[hidden]> wrote:
> 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.

I have just been experimenting with modifications to the
internal reactor interfaces such that they will attempt a
non-blocking operation first, and only add the requested event
to epoll if it doesn't complete immediately. In cases where
descriptors are chronically ready, this bypasses epoll system
calls altogether. Rough indication so far is that it improves
performance 10-20%.

> 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'm happy to provide "private" methods to allow you to choose
the backend, such as a #define, or something that defers the
choice to runtime. My point is that it should not be part of the
public interface, since:

- These implementations are inherently non portable, and
  portability is the goal.

- Adding things to a public interface implies that they are
  stable and will not be taken away in the future. Suppose some
  new demuxing technique comes along -- whether it be a new
  OS-level feature or a better way of utilising existing ones
  -- or an existing technique becomes obsolete, should asio's
  interface provide a guarantee that your chosen implementation
  is still supported? To me, it should not. Exposing these
  implementation details is likely to lead to onerous backward
  compatibility and maintenance requirements, and restrict the
  ability to optimise for the far more common use cases.

As I said above, I'm willing to provide a private mechanism for
choosing the implementation. I just don't believe that this is
something that I can publish public interfaces for.

Cheers,
Chris