Re: [boost.async] Seeking Endorsement

From: Richard Hodges (hodges.r_at_[hidden])
Date: 2023-07-25 19:42:02

On Tue, 25 Jul 2023 at 20:32, Christian Mazakas via Boost <
boost_at_[hidden]> wrote:

> > Not if we want users. Coroutines ate much more relevant at this time.
>
> The problem is, this definitely isn't true.
>
> Users already have Asio's `use_awaitable`. A coroutine library that uses
> Asio as its event loop is basically a lateral move from, well, just using
> Asio
> with `co_spawn` and `use_awaitable`.

Asio’s primitives are incomplete. I say this as a fan of asio.

>
> Not like I wanna veer off too far into the weeds here about Requests
> vs whatever.
> But I really don't think coroutines are much more relevant than a
> robust HTTP client
> that's written using Asio's coroutines today.

I believe Klemens is quite far into requests but on that journey it became
apparent that primitives were needed to make async IO and coroutines inter
operate nicely. I have been on the same journey and came to the same
conclusion.

>
> But I feel like I have a better understanding of the library now and its
> goals.
>
> > And it'll provide functionality that should be in the standard, just
> > like boost did before 2011.
>
> The problem is, this also isn't true.
>
> This kind of functionality should never touch the standard because it
> ties a coroutine
> to an execution context. In fact, I'd argue this library's biggest
> mistake is doing exactly that.

Respectfully you are wrong about this. Every implementation of coroutines
and IO centres around an implicit or explicit IO dispatch loop. Python,
JavaScript, asio, etc. this is because you can’t do async IO without an IO
loop.

Asio abstracts the native IO loop on each target.

>
> What I'm thinking of is something like cppcoro's task type, a task
> type that can only be co_await'd
> by a parent coroutine. To this end, `cppcoro::task<T>` can appear in
> interfaces and then runtime
> authors are free to invoke this via their own runtime-specific
> coroutine types. cppcoro's task stores
> the type-erased coroutine_handle when it's transformed into an
> awaitable so it works with all
> parent coroutine types.

C++ lacks out of the box utility. This library has made firm choices about
interface design and implantation in order to provide that out of box
experience without the landmine experience, while still allowing
customisation by experts.

>
>
> I think we need vocabulary types like that, with schedulers set
> alongside them. It worries me to see
> an executor directly tied to a coroutine when it's really not
> required, let alone purported that this
> should actually be a standardized practice. There's definitely room
> for innovation in the coroutine
> space but it's hard to argue for a "coroutine library" that I can't
> even use without bringing in Asio.

If you’re using boost, asio is free. The library requires a tiny subset of
ASIO, and optionally allows the author to work with all of asio and any
asio-compatible library, seamlessly. And incidentally with better
performance than ASIO coroutines, either stackless or stackfull.

Tying executors to coroutines is absolutely necessary unless you want users
to have to contend with thread synchronisation or jitter manually.

This library takes all these concerns away.

>
> - Christian
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- 
Richard Hodges
hodges.r_at_[hidden]
office: [phone]
home: [phone]
mobile: [phone]