Re: [boost] Late asio review

From: Christopher Kohlhoff (chris_at_[hidden])
Date: 2006-01-12 08:23:16

Hi Chris,

--- Chris Cleeland <cleeland_at_[hidden]> wrote:
<snip>

>    (a) buffers: from a certain perspective, this sounds nice,
>    but it seems that there are already so many abstractions
>    over a (void* + length)

There are? :)

>    --do we REALLY need another?  Could this be simplified to
>    something like std::pair<void*, std::size_t> ?

Conceptually, mutable_buffer does behave like
std::pair<void*,size_t>, and const_buffer is like
std::pair<const void*,size_t>. However, unlike just using
std::pair, the buffer classes also:

- Make type-safety violations explicit (although not impossible)
  by requiring you to use buffer_cast.

- Provide some protection against buffer overruns by only
  allowing smaller buffers to be created from larger ones.

>    I don't see how one can get hold of the raw socket
>    descriptor to twiddle options that the library hasn't
>    abstracted.  

Two methods:

- Use the impl() member function to get access to the underlying
  platform-specific implementation. E.g.:

    ::setsockopt(sock.impl(), ...);

- Implement the Socket_Option concept for the option.

<snip>
>    I also know that after 15+ years of network programming,
>    KNOWING the details all the way down to the wire is
>    important for how one writes code.

If an application requires that level of control, then asio is
probably not the appropriate tool.

>    Purists may say that one should never make such
>    assumptions, but the reality is that when your "wire" is
>    gigabit ethernet you get to write code with a certain set
>    of assumption that is completely different from assumptions
>    in place when the "wire" are high-bandwidth/high-latency
>    satellites in geosynch orbit.

I'm genuinely curious to know what assumptions are different
between those two specific scenarios, with respect to
demultiplexing.

<snip>
>    Is hostname resolution really so much of an overhead that
>    we need asynch hostname resolution?  If the feature were
>    basically "free", I would say okay, but the fact that it
>    requires firing up an extra thread behind the scenes
>    (another one of my pet peeves) makes it seem like a wholly
>    unnecessary feature.

The issue here is that hostname resolution is a potentially
lengthy operation. If resolution is only performed at program
startup, then that might be ok. However, if a server needs to
resolve hostnames on a regular basis, you would not want to
block the flow of control and delay other clients.

If the synchronous operations were all that was on offer, the
only course open to the application developer would be to use
threads. The asio philosophy is to offer application developers
support for concurrency without the need to use threads
directly.

As a bonus, some platforms do provide asynchronous host
resolution APIs, and I hope to support these over time. This
would be transparent to users of the asynchronous host
resolution.

>    Besides the fact that this style is "wierd" to me (that's a
>    personal thing), this implementation choice forces users'
>    hands down the line.  First, it forces all the code in the
>    "library" to be replicated in every executable.  This is
>    not efficient and increases footprint.

It is on my to-do list to add support for a library
implementation. However the goal of this is to prevent system
headers from polluting the application's namespace.

Since most of the library is template-based, I don't expect it
to make much difference to the footprint (although you never
know).

> 4. How would I implement a timed write with the current async
>    API? By "timed write", I mean that I want to write some
>    hunk of data, but I need to know if the write hasn't
>    completed within a certain window of time.  This is a
>    common need in performance-sensitive systems, and writing
>    it synchronously can be done, but how do I write it asynch?

The timing bit is easy: just set the expiry on a deadline_timer
and perform an asynchronous wait. However the real question is
what to do once the timer fires :)

Can you describe the wider use case in more detail? In
particular, what you intend to do with the socket if the "timed
write" times out.

At the moment the way to cancel operations in asio is to close
the socket. All pending asynchronous operations complete with
the operation_aborted error.

> 5. TSS and threads
>    Shouldn't these rely on boost.thread?  I'm especially
>    thinking of TSS in this case, bceause in ACE/TAO we've
>    found that TSS is, at the very least, inconsistent across
>    platforms.  See changelog entry in
>    ACE_wrappers/Changelogs/ChangeLog-05a for one of t he more
>    aggregious examples.
>
>       Wed Feb 16 16:18:45 2005  Dale Wilson <wilson_d_at_[hidden]>

Unlike both Boost.Thread's and ACE's TSS implementation, the TSS
wrapper in asio provides absolutely no ownership or cleanup
semantics, thus avoiding painful issues like the ones mentioned
in that ChangeLog entry. It's used only to store a pointer to a
variable on the stack.

Cheers,
Chris