From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2024-07-16 19:35:23
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