Reimplementing ASIOs (was: Re: Boost Foundation, Boost, and the Beman Project)

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-07-16 16:45:16

On 12/07/2024 16:18, Christian Mazakas via Boost wrote:
>> Niall Douglas via Boost
>> That gap has reopened since. My last two jobs have seen me
>> reimplementing ASIO several times over now, as that's what the customer
>> wants.
> 
> I'm guessing these were custom event loops around io_uring? If so, we should
> talk shop someday, Niall.

My current employer is Linux only, so I've been able to very tightly 
wind this thing around io_uring. My current latest iteration is 
completely wait free, malloc free, lock free and 100% deterministic 
around io_uring. I also implemented priorities so some work gets 
prioritised over other work, and that is separate to i/o priority for 
io_uring (which has no effect anyway for most default kernel configs).

A nice thing is that the benchmarking tool written on top of my stuff 
shows 8-10% better results than the fio tool, written by Axboe himself. 
It is that more efficient.

> It's kind of interesting, once you get the hang of writing an event loop,
> this
> isn't such a daunting task if you're able to bring over and port a good
> portion
> of tests.

Depends on the idiom. My current latest iteration fuses a Boost.Fiber 
type stackful coroutine in with the i/o execution. So when you're 
writing your code, your current execution context will suspend and 
resume as i/o initiates and completes. Basically it's a kernel thread 
scheduler, and indeed the entire thing is written in C as that is the 
employer's wish.

Thankfully C 23 is the least painful C to write in yet. I principally 
miss lambdas, but otherwise it's not too bad.

Outcome is shortly going to receive much improved C support. Outcome has 
shipped with C support since the beginning, but it will shortly be first 
tier instead of second tier support.

In any case, the stackful coroutine type approach is _very_ different to 
the Senders-Receivers type approach which my preceding ASIO 
reimplementation used. Tests need basically rewriting. I have, of 
course, written a portability layer so the new implementation can quack 
like the old one, and that should enable migration of the work codebase.

> Plus, this kind of makes sense for most shops. You use C++ 'cause you care
> about
> low-level stuff and you'd wanna own this portion of your tech stack.

You're definitely right that enough performance is left on the table 
with ASIO that it's worth shops investing in their own custom 
implementation if they care enough about the last few percent.

Our codebase is currently Boost.Fiber based, and getting off that is 
worth the investment. As anybody who has used it for real world 
applications will have experienced, it has 'quirks'.

Niall