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/