|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk