Re: [boost.async] Some questions

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-08-13 09:55:22

On Sun, Aug 13, 2023 at 5:33 PM Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
>
> Hi Everyone,
> I would like to thank Klemens for writing and sharing this library. I am
> sure the community needs a higher level library for asynchronous
> computations based on C++20 coroutines. Boost.Async addresses the need. I
> would like to ask a couple of questions to better understand the design
> goals and the scope of the library.

Thanks for looking into the library.

>
> Q1. Is single-threaded-ness the design goal? Or is the plan to enable
> multi-threaded use cases? There is a GitHub issue (
> https://github.com/klemens-morgenstern/async/issues/19) suggesting the
> latter.

I think most of the use cases for asynchronous code are best served
being single threaded.
That is you have a single IO thread and offload intense work (e.g.
complex calculations) onto a thread pool.

You can have multiple threads using async, but they can't interact
safely with each other.
I am considering adding support for that, but that's already possible
by using asio's concurrenct_channel. So it's not high on the priority
list.

>
> Q2. Reading through the docs, I get an impression that Boost.Async is
> "Either a wrapper over ASIO, or an isolated usage for a generator". They
> seem like two unrelated worlds. The former requires a hard prerequisite of
> having a Boost.ASIO library (with Boost version at least 1.82). The latter
> can hardly be called "asynchronous". Generators, the way I understand them,
> are perfectly synchronous. Is this impression correct?

It is not. Generators are also async, i.e. they run on an event loop
and can to asynchronous co_awaits.

I also don't think "wrapper" is the correct term;
async is like any coroutine library in that it needs an event loop
(some of which are built into the language).
So it uses asio's which I considered the best choice.

>
> The following are more remarks regarding the choice of names.
>
> Q3. The docs say that `promise` and `task` differ primarily by their level
> of eagerness. But the names do not seem to reflect this. What is the
> rationale or the intuition behind those names?
>

Promises are eager in JS, tasks lazy in Python. Can also be remembered
like this:
If you make a promise you should see it through eagerly, while a task
can wait until it's scheduled.

>
> R1. I find the name `use_op` uninformative. The examples in documentation
> suggest that it is an *adapter*: they change the Boost.ASIO interface into
> the Boost.Async interface. Is that correct?

Technically into an expression that can be used with co_await from any
coroutine.

All of asio's completion tokens are *adapter*s in a sense, e.g.
use_future adopts it into a std::future.
The type returned is an implementation of `op`, so `use_op` matches
the asio pattern here.

>
> Regards,
> &rzej;
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost