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