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

From: Jody Hagins (jody-boost-011304_at_[hidden])
Date: 2005-12-22 17:50:01

On Fri, 23 Dec 2005 09:09:41 +1100 (EST)
Christopher Kohlhoff <chris_at_[hidden]> wrote:

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

Well, you know...  I'm looking for the numbers now.  I seem to have not
only lost the numbers, but the program as well.  If I can't find them,
then maybe I'll just rewrite the test (as close as I can come to
remembering it) on Christmas Day.  I should be allowed to do SOMETHING
fun on that day...

> The standard multicast socket options are implemented in the
> asio::ipv4::multicast namespace. They are:

There are some other (not so standard, and ipv6) ones, but that should
do for now.

> From comments, you'll seed that some people prefer header-only
> and others don't.

Right.  Wish there were a way to do both...

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

I actually played with a lib implementation using templates.  Ended up
templatizing on const builtins with values set to the "actual" value
from the system header.  It's a bit ugly in the implementation, but the
usage is quite nice, and a bit more readble.  It's is, at least,
possibly to do all your template stuff (like socket options and such) in
such a manner, without including the system headers directly.

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

That's OK.  The part I don't want included is the OS related junk. 
That's where my namespace gets polluted, and that's where funky macros
come from.  All your stuff will be nicely wrapped in the boost::asio
namespace.

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

Yes, I agree.  I still think you can do it without the memory
allocations.  Basically, you are wrapping the system level stuff
(anything that needs non-boost headers) in a library, and providing a
think interface (it can even be templates for the most part).

There will be a performance cost for the extra function call.

While I've been extremely busy, I did try to read the docs.  I'm
concerned about all the bind() calls.  I can live with it the first
time, but it looks like I have to rebind after each operation.  This can
be quite costly.  Maybe I'm missing something...

I'll try to get some time over the next week to review it a bit more,
but this time of year is HECTIC.  Kids, XMAS, work deadlines, end of
quarter deadlines, end of year deadlines, etc... etc...  I even canceled
my vacation time (went skiing last weekend with the kids, but other than
that, it's all been canceled).