On Tue, 25 Jul 2023 at 20:32, Christian Mazakas via Boost < boost@lists.boost.org> 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@gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212