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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-22 15:07:48

On Thu, 22 Dec 2005 23:29:53 +1100 (EST)
Christopher Kohlhoff <chris_at_[hidden]> wrote:

> If I'm understanding you correctly, what you are after is a
> single program, where you you have some sockets using one
> demuxing method (say epoll) and other sockets using (say)
> select? Interesting.

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.

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?

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?

While I haven't played, I assume it works under BCB ;-)