Re: [boost] ASIO into the standard

Subject: Re: [boost] ASIO into the standard
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-07-01 06:23:10

On 1 Jul 2014 at 13:41, Gavin Lambert 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. :)

It's hassle though. And could have been avoided altogether, though 
then you would no longer have the present design so it's probably too 
late now.

BTW, I believe the locks ought to be elidable if you have STM or HTM 
available, so ASIO could have an entirely wait free implementation in 
its fast path. AFIO achieved this, I'm sure the same pattern could be 
used for ASIO.

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

iTrue. It still annoys me though that you can't concurrently use the 
same socket for reads and writes, so either you strand or you go all 
async throughout. I'd prefer all async as the thing to be 
standardised, it's then trivial to build synchronous functionality on 
top with whatever concurrency model you prefer. Less is more here I 
think.

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

Well ... AFIO provides a stable ABI which contains and isolates the 
platform specific implementation. Said ABI isn't really intended for 
humans to write against, but rather metaprogramming to assemble for 
you. I see no reason ASIO couldn't be similarly structured if one can 
assume C++14 as a minimum. A lot of why ASIO is the way it is is due 
to C++ 03.

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

I agree with this claim. Bugs which appear in one function e.g. 
truncating data sends to 64k can usually be worked around by using 
another function. There is indeed too much copy and paste 
implementation in there, and as you said it's mostly due to the 
template concept stuff all of which was forced by 03's inferior 
facilities. constexpr alone would transform a ton of that stuff, it 
could potentially as a guestimate lop 40% of lines of code off the 
implementation.

I think it's going to be very tough to standardise ASIO :(

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/