Boost logo

Boost :

Subject: Re: [boost] ASIO into the standard
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-06-30 21:41:20

On 1/07/2014 08:09, Niall Douglas wrote:
> There is also a strong argument that anything in ASIO which isn't
> async needs to go. Plus, some might feel that ASIO's current design
> uses too much malloc for embedded systems/ultra low latency, and I
> would sympathise :)

Most of the mallocs can be avoided by using the custom allocator
framework. It's the locks that I object to from an embedded-low-latency
standpoint, and why I ended up rolling my own. :)

That's only really an issue though if you're trying to use it for
generic-embedded-async or at least non-network-async purposes. Once
you're using it for its original purpose of network I/O, locks make more

> Finally, as a personal viewpoint I don't care much for ASIO's
> internal implementation. I find it obtuse and hard to debug or indeed
> figure out much at all as bits of implementation are scattered all
> over the place. Some if not much of that is because ASIO implements a
> sort of generic concept type framework all of which requires
> checking, well the obvious course of action here is to use proper C++
> 17 concepts and do away with the legacy design cruft. I'd also
> personally split the genericity away from the implementation, and
> push the implementation into a non-header built stable ABI so we can
> avoid pulling in so many system header files like all of windows.h.

Unfortunately one of its most powerful features (concept based callable
handlers and the ability to chain special conditions such as custom
allocators and strands) also means that templates permeate almost
everywhere, making it really hard to do anything other than header-only.
  (I haven't read up on C++17 concepts and whether they would help with
this or not.)

When I was rolling my own one I did elect to use private implementation
instead but it came at a cost of flexibility and performance
(particularly since I'm using boost::function to break the template
chain instead of something more lightweight); in particular mine doesn't
support custom allocators and while it does have strands, they're a bit
more brittle and you need to be more careful how you use them or you can
get unexpected concurrency. (It's still a net win in my case due to
lower latency and lock avoidance, but this is not a tradeoff everyone
would want to make.)

I might be wrong about this, but I get the impression that a lot of the
internal implementation code is duplicated rather than being factored to
common methods in order to avoid conditionals and improve performance
without relying on compiler inlining. Which can also contribute to
making it hard to read and understand.

Boost list run by bdawes at, gregod at, cpdaniel at, john at