On 16/07/2024 20:12, Christian Mazakas via Boost wrote:
Sounds sick. You should paste a link if you can.
Employer's code, not mine. They'll be open sourcing everything next year, and unlike most promises of that kind in this situation they really will have to.
Check this out: https://github.com/cmazakas/fiona
It's a take two on Asio that aims to fix all of the things I found annoying about it. Namely, my implementation here actually supports foreign awaitables because I just copied Rust's Waker approach.
I'm all for foreign awaitables support. Everything I do in C++ coroutines allows arbitrary awaitable types. A library has no business imposing what users can use there in my opinion, and Klemens of course took that boat right out to sea with Boost.Cobalt. But ... I don't agree with hard coding in C++ coroutines personally. I think Sender-Receiver (before WG21 corrupted it) is a better design choice here especially as if within a C++ coroutine you can co_await and it'll "just work" without any extra effort. Here's what I did: - Free function `co_initialize()` connects a Sender to an appropriate C++ coroutine resuming Receiver and launches it. - Free function `initialize()` is a customisation point for how to launch connected S&R states. - Free function `connect()` is a customisation point for how to generate connected S&R states. So, as an example, you might `connect()` a Sender to a `boost::fiber::future` and that would connect to a Receiver which sets the future's promise on completion. As you can see, this is very flexible, and you can completely avoid all malloc-free cycles entirely which C++ coroutines make it hard to do. (My new 100% C executor has runtime switchable context switchers, so you can configure a C++ coroutine context switcher if you want. It being C it just isn't compile time enforced nor checkable, that's all) I see in your github repo you are benching against ASIO. What kinds of results did you get? Niall