From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2005-12-22 17:09:41
--- Jody Hagins <jody-boost-011304_at_[hidden]> wrote:
> Note that each is good for specific things. I have tests and
> numbers that show select() and epoll() running circles around
> each other in performance, depending on the way they are used.
> Mixing the different types of use-cases causes both methods to
> degrade. Thus, I think it is very reasonable to put some
> sockets into a select-based method, and other sockets in an
> epoll-based method.
I guess you must be doing some pretty hard-core networking to be
concerned about this level of detail. Can you describe a use
case that would make such a feature widely useful? Some hard
numbers on performance differences would be quite interesting.
> BTW, I've yet to have time to do a review (I have a major
> deadline Dec 23, then xmas stuff for a few days).
> However, I've tried to follow some of the comments.
> One of my biggest problems with asio, when I tried it several
> months ago, was the poor support for datagram/multicast apps.
> I've seen that you have addressed some concerns (at least
> according to some comments). Could you please specify some
> details of the mcast improvements?
The standard multicast socket options are implemented in the
asio::ipv4::multicast namespace. They are:
> Also, the motivation for your own thread implementation is an
> all-header implementation of asio. Why do you need an
> all-header implementation? In the earlier requirements for a
> boost network library, NOT having an all-header implementation
> was one of the requirements.
> Personally, I do not like all-lheader implementations,
> especially for system related components. They pull way too
> much junk into the namespace, especially under any flavor of
> Windows (though linux has its own problems there as well).
> Lots of macros, and other junk to pollute and cause problems
> -- not to mention the additional compilation time...
> What's wrong with a library-based implementation?
>From comments, you'll seed that some people prefer header-only
and others don't.
It's on my to-do list to investigate a library implementation,
but this would be an option, not mandatory. The goal of the
library implementation would be to hide away the system headers.
However, a few things need to be considered:
- Much of the library is implemented in templates, so it is
likely that only the lowest level OS wrappers would be in a
- I am very concerned that any compilation firewall technique
used does not introduce additional memory allocations. I am
not yet sure about the best way to achieve this. Some
declaration of system types may be required (albeit in a
namespace), for example.
> While I haven't played, I assume it works under BCB ;-)
Yes, mostly :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk